Bug in Axent 5.0

[sjackson () AXENT COM (Steve Jackson)]

AXENT appreciates the opportunity to respond to the issues raised with this
posting.  The first statement indicates that users cannot log into scanned
hosts.  This is not true--users can log in, but they will not be able to
access their startup scripts.  This bug constitutes more of an inconvenience
to the user, than a security threat.

The bug was discovered a short time ago and there is a current procedure for
correcting the ownership of files that may have been affected.  Currently
there is a newer version of the affected usrfiles module that does not
change the ownership of the startup scripts. This procedure and/or the
updated module can be obtained by contacting AXENT support.  This version of
the usrfiles module is also included in the August HotFix for ESM that
customers can remotely install on all systems.  The hot fix is only needed
for ESM 5.0 UNIX agents. Earlier versions of ESM agents do not have this
problem.  The fix will also be included in the upcoming ESM 5.0.1 release.

As was indicated in the original posting, this check was not turned on by
default and most ESM 5.0 customers have probably not used it.   If you
desire the procedure to correct the affected files or the updated module,
please contact AXENT support at  support () axent com
<mailto:support () axent com>  .

Thank you,

Steve Jackson
ESM Technical Product Manager

                -----Original Message-----
                From: Aleph One [mailto:aleph1 () SECURITYFOCUS COM]
                Sent: 13 July 1999 12:11
                To: BUGTRAQ () SECURITYFOCUS COM
                Subject: Bug in Axent 5.0

                Bug in Axent 5.0 for Unix
                Bugtraq ID 518

                This information was forwarded to Security Focus.

                 Certain checks within Axent's ESM 5.0 for Unix may prevent
legitimate
                 users from logging on to scanned hosts.

                 Specifically, four checks within the security auditing
program may cause
                 this denial of service:

                 * Check PATH using 'su'
                 * Check PATH by modifying startup script
                 * Check umask using 'su'
                 * Check umask by modifying startup script

                 These checks are not enabled in the default policy
templates.

                 When ESM is checking PATH (or umask) values, it will 'su'
to the user's
                 account. If the user's script calls a menu function, ESM
will not respond
                 and the check will hang. To overcome this problem, ESM
copies the
                 startup script to the /tmp directory, adds additional
values to the end of
                 the script, and copies the script back to the user's
directory. The new
                 values in the script will echo the PATH and umask values to
a file called
                 .esmvalues in the user's home directory the next time the
user logs in.
                 When ESM is run again, it will read the contents of
.esmvalues to
                 determine the PATH and umask values. This procedure
eliminates the
                 problems associated with 'su'ing to the account and hanging
on a menu
                 call.

                 Unfortunately, when ESM copies the file to /tmp, file
ownership and
                 permissions are changed to 'root'. When the file is copied
back to the
                 user's directory, only root has access - legitimate users
will not be
                 able to execute their login script.

                 This bug should be fixed in the upcoming 5.0.1 release.

                --
                Elias Levy
                Security Focus
http://www.securityfocus.com/