COMMAND

    CDE

SYSTEMS AFFECTED

    DU 4.0CDE

PROBLEM

    Harhalakis Stefanos and Psarras Nikos found following.  On Digital
    Unix  4.0E  with  the  latest  patch  kit  aplied,  after  a   new
    installation /var has g+w for group system.  Anyone that can crack
    any  account  with  gid==system  may  exploit this (not tested but
    there should  be no  problem with  mv'ing /var/sbin,  /var/adm etc
    etc..).  It seems  that CDE is forcing  g+w to  /var..   The whole
    thing is  done while  executing /sbin/rc3.d/S95xlogin  and only if
    CDE is selected.  Note that  this problem seems to exist in  other
    versions of Digital Unix, too.  At least on Digital Unix 4.0c  and
    4.0d (Factory Installed Software, no patches applied, CDE in  use)
    /var, which in this case is a link to /usr/var, has

        drwxrwxr-x  28 root     system       512 Feb 11 12:58 /usr/var/

    permissions.   However,   on   Digital   Unix   4.0b   (Patch  kit
    DUV40BAS00008- 19980821 applied,  Software installed from  CD, CDE
    in use) /usr/var has

        drwxr-xr-x  23 root     system       512 Feb 11  1998 /usr/var/

    permissions.     Also,   there   is   no   chmod   of   /var    in
    /sbin/rc3.d/S95xlogin (at least Digital Unix 4.0c and 4.0d).

    Another kind of exploit should look like following.  CDE's Xconfig
    file is  a link  from /var/dt/Xconfig  to the  actual config file.
    Moving /var/dt and  creating your own  /var/dt, you could  replace
    the  system  Xconfig  file  with  your  own  version which has the
    session manager specification

        Dtlogin*session:               /usr/dt/bin/Xsession

    replaced with  something more  evil.   Then just  wait for root to
    log in on the console....

SOLUTION

    Under  Digital  UNIX,  the  system  group  is  the  group  that is
    'pseudo-root', i.e. have near  root privilages and are  allowed to
    su into root.  /var, which under a default install, is a  sym-link
    to /usr/var, contains all of the system accounting files, LSM, and
    other system specific files  that all System Administrators  would
    need to run thier system.  So, it is only logical that system have
    write permissions to that directory.   Also, one should note  that
    any system  administrator should  (and would),  only put  _secure_
    accounts in the system group, i.e.   any account that is going  to
    utilize a safe password and  those accounts are not going  to have
    set-uid or gid executables attached to them.

    One  more  note:   as  an  ls  -la  of /sbin/rc3.d would show you,
    S95xlogin is only a sym-link  to /sbin/init.d/xlogin.  The S95  is
    there so when init comes up to run level 3, it will start (the   S
    tells it that), and  the 95 is placed  there to put it  in order -
    you add a numeric number to  the front of the executable, so  when
    the  rc3  script  processes  /sbin/rc3.d,  it  gets launched after
    certain daemons and programs that need to be running in order  for
    it to  start.   To the  best of  my knowledge,  xlogin isnt  doing
    anything to the /var permissions.

    Anyway, to solve this do not  have any users in the system  group.
    Beware also of permissions on /var/dt. In your /sbin/init.d/xlogin
    You may insert  (within the function  StartDisplayManager(), after
    the line '$X_DISPLAY_MANAGER -daemon $CONFIG_OPTION'):

        ### Change by PSz on 12 Nov 96
        ### Stupid /usr/dt/bin/dtlogin uses 'chmod 777 /var/dt'. This is bad...
        ### Also watch out for /usr/dt/config/Xsession.d/0030.dttmpdir
        chmod 755 /var/dt > /dev/null 2>&1
        # Sleep to make sure dtlogin is finished, do again
        sleep 10
        chmod 755 /var/dt > /dev/null 2>&1
        ### End of change