Re: An ugly exit. *EXITRG that is. -- MIDRANGE-L

This thread has created a an environment of assumptions and is now being
used by an unscruPulous security vendor as a sales and marketing tool to
mislead their own customers about Bytware and our StandGuard products. So,
to protect the integrity of our company, our products, and to ensure
everyone reading this thread have the facts, I am setting the record
straight on what is and isn't happening with respect to this problem.

Mr. Crosby is having an object integrity problem. How do we know that?
Because he has a system object that is getting damaged. How does a system
object get damaged? There are only 3 ways:

1. The object is modified by a 3rd party program using unsupported
interfaces. In this case the object that is getting damaged is the exit
point registry. Very unlikely that a program would need to modify the exit
point registry since there are pretty good APIs for dealing with that. But
fortunately we don't have to guess because OS400 provides easy ways for us
to detect that -- we leave our security level at 40, and we run a CHKOBJITG
to find any programs on our system that are set to run in a system state. If
Mr. Crosby ran a CHKOBJITG over STANDGUARD he would find there are NO
programs that we own that run in a system state. And hopefully there aren't
any other non-IBM system state programs on his system either -- again an
easy thing to check. So we can rule out this option as the culprit.

2. A power outtage. Since this problem occurred 3 times without the power
ever going out we can safely rule out this option too.

3. A bug in the OS. A system state program is the ONLY way the object can be
changed. PERIOD. One must realize that an OS program has the object open and
is overwriting storage. Either some code is not in sync with the object or
it is using a non-threadsafe method to access storage in a multi-threaded
environment. This is more likely what is happening.

If there is a land mine somewhere in XPF or LIC and we are stepping on it
then so be it -- that could happen to anybody.  I can understand that a
customer might not fully understand these facts, but any worthy iSeries
security vendor would know this and it is unfortunate that Mr. Crosby's
postings and the respondents replies implying or concluding without fact
that STANDGUARD or Bytware is somehow responsible for the exit point
registry getting corrupted is ridiculous.

Finally, if you are a customer who has received emails from another security
vendor referencing this thread, Bytware, and/or StandGuard, please contact
us for clarification.

Bruce or Pat please chime in here if you have anything to add.

Mike Grant
CEO
Bytware, Inc.




Jeff -


I'd be uninstalling Standguard and asking them for a refund...


Steve

----- Original Message ----- From: "Jeff Crosby" <jlcrosby@xxxxxxxxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'" <midrange-l@xxxxxxxxxxxx>
Sent: Wednesday, March 02, 2005 10:20 AM
Subject: An ugly exit. *EXITRG that is.



All,


I have posted on this before, and here I go again.

For the 3rd time since going to V5R3 last September, I lost all FTP and
REXEC exit points. This happened yesterday morning. Since 98% of customer
orders arrive on the i5 via FTP and are processed by a command issued via
REXEC from another system, this is a real problem for us.

The first time this happened was on the 270, we have since gone to an i5 520
where it has happened twice. This morning many of the MSF exit points were
missing. All 3 times it has happened this way. FTP and REXEC one day, MSF
the next. A simple call replaces the FTP and REXEC exit points, but MSF
exit points must be replaced manually one by one.

Each time it has happened, it was immediately after either loading or
upgrading the Standguard Antivirus from Byteware. I pitched a Holy H***fit
to Supportline. They have at least 8, and maybe 10, developers working on
finding out what in the world is going on. IBM says they don't believe that
Standguard is the problem, per se, but that something that Standguard is
doing is not being handled properly by IBM. IBM and Standguard are in
contact with each other on this issue.


We made a bit of headway yesterday by finding this in a joblog:

CPD3C69 Diagnostic 30 03/01/05 05:02:42.839032 QUSRGFA2 QSYS *STMT QP0FEPFS
QSYS *STMT 
>From module . . : QUSRGFCM
>From procedure  : CHKAUT_OBJ_HDLR

Statement . . . : 78
To module . . . : QP0FSCAN
To procedure . : Qp0fCallScanExit__FP10EPFS_VnodeiLUi23qp0lScan
ExitProgramType
Statement . . . : 99
Message . . . . : Object QUSEXRGOBJ in library QUSRSYS recreated.
Cause . . . . . : The secondary space pointers in object QUSEXRGOBJ were not
set, and the object is not usable. The object has been recreated with new
secondary spaces. A loss of data may have occurred. It is recommended that
you restore this object from your backup tapes.

The above was from job 068258/QSYS/QCSTCTHRMD. (A clustering job. We don't
use clustering so IBM removed the autostart job entries.) This explained
how the exit points disappeared (because QUSEXRGOBJ was recreated) but not
what caused QUSEXRGOBJ to become unusable.


The Standguard virus scan also failed last night.  Something about an exit
point.  Go figure.  I'll be calling them shortly.

If anyone else is having a similar issue with exit points and/or Standguard,
I think IBM would be interested. They're looking for all the info they can
get.


--
Jeff Crosby
Dilgard Frozen Foods, Inc.
P.O. Box 13369
Ft. Wayne, IN 46868-3369
260-422-7531


The opinions expressed are my own and not necessarily the opinion of my
company.  Unless I say so.



CONFIDENTIALITY NOTICE:  This e-mail message and any attachment to this e-mail 
message contain information that may be privileged and confidential.  This 
e-mail and any attachments are intended solely for the use of the individual or 
entity named above (the recipient) and may not be forwarded to or shared with 
any third party.  If you are not the intended recipient and have received this 
e-mail in error, please notify us by return e-mail or by telephone at 
775-851-2900 and delete this message.  This notice is automatically appended to 
each e-mail message leaving Bytware, Inc.