Vulnerability

    axent

Affected

    Axent 5.0 for Unix

Description

    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.

Solution

    This bug should be fixed in the upcoming 5.0.1 release.  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 above, 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.