Re: 2.4.x/Slackware Init script vulnerability

From: Derek Martin (ddmat_private)
Date: Tue Jul 17 2001 - 13:32:07 PDT

  • Next message: Haroon Meer: "Firewall-1 Information leak"

    On Mon, Jul 16, 2001 at 09:53:01AM -0500, joshat_private wrote:
    
    > I posted this to the linux kernel mailing last Friday, July 13th 2001:
    > 
    > Submitted by  : Josh (joshat_private), lockdown
    >                 (lockdownat_private) on July 16th, 2001
    > Vulnerability : /lib/modules/2.4.5/modules.dep
    > Tested On     : Slackware 8.0. 2.4.5
    > Local         : Yes
    > Remote        : No
    > Temporary Fix : umask 022 at the top of all your startup scripts
    > Target        : root
    > Big thanks to : slider, lamagra, zen-parse
    > Greets to     : alpha, fr3n3tic, omega, eazyass, remmy, RedPen, banned-it,
    >                 cryptix, s0ttle, xphantom, qtip, tirancy, Loki,
    >                 falcon-networks.com.
    > 
    > 	The 2.4.x kernels starting with 2.4.3 (i think) have, after
    > load, left a umask of 0000.  This forces any files created in the bootup
    > scripts, without the command `umask 022` issued to be world writeable.
    > In slackware, files include /var/run/utmp and /var/run/gpm.pid.  This same
    > vulnerability is responsible for creating /lib/modules/`uname -r`/modules.dep
    > world writeable.  With this file world writeable, all an intruder need do is
    > put something like the following in /lib/modules/`uname -r`/modules.dep
    > assuming the system's startup scripts modprobe lp:
    
    I messed around with this on a Red Hat 6.2 system (with
    modifications), by DELETING the existing 
    /lib/modules/`uname -r`/module* files and rebooting, 
    and got the following results:
    
    
      [ddm@sol ddm]
      $ modprobe -V 
      modprobe version 2.4.3
      modprobe: Nothing to load ???
      Specify at least a module or a wildcard like \*
      [ddm@sol ddm]
      $ uname -r
      2.4.5
      [ddm@sol ddm]
      $ cat /etc/redhat-release 
      Red Hat Linux release 6.2 (Zoot)
      [ddm@sol ddm]
      $ ls -l /lib/modules/`uname -r`
      total 44
      lrwxrwxrwx    1 root     root           20 Jun 30 09:17 build -> /usr/local/src/linux/
      drwxrwxr-x    5 root     root         1024 Jun 30 09:17 kernel/
      -rw-rw-rw-    1 root     root         6778 Jul 17 08:17 modules.dep
      -rw-rw-rw-    1 root     root           31 Jul 17 08:17 modules.generic_string
      -rw-rw-rw-    1 root     root          519 Jul 17 08:17 modules.isapnpmap
      -rw-rw-rw-    1 root     root           29 Jul 17 08:17 modules.parportmap
      -rw-rw-rw-    1 root     root        10683 Jul 17 08:17 modules.pcimap
      -rw-rw-rw-    1 root     root        18801 Jul 17 08:17 modules.usbmap
      drwxrwxr-x    2 root     root         1024 Jun 30 09:17 pcmcia/
      drwxr-xr-x    2 root     root         1024 Jun 30 09:37 video/
    
    
    I also did the same thing on a Red Hat 7.1 system, with modutils 2.4.2
    (as shipped by Red Hat), and linux 2.4.5 (pristine), and the modules.*
    files were recreated with permissions 0644 upon reboot, so it seems
    not to be limited to just Slackware, but also not a universal problem.
    Since it did not happen on RH 7.1 with modutils 2.4.2, it may be that
    the problem is actually in modutils 2.4.3 (and later, probably), and
    not in earlier modutils.  I think this is probably not really a kernel
    issue, per se.
    
    After finding these results on my RH 6.2 system, I changed the
    permissions on the modules.* files from 0666 to 0644 and rebooted
    again, and the 0644 permissions were retained when depmod -a ran from
    /etc/rc.d/rc.sysinit (which makes sense).
    
    I would think that modutils should set the creation mode to 0644 when
    creating these files.  I would also think that as a security measure,
    modutils should verify that these files (or at least modules.dep) are
    not world-writable (and probably also not group writable) BEFORE
    loading modules as a result of listed dependencies...  I'm not really
    sure that the kernel itself should automatically set a restrictive
    umask, as I would think it should be up to user-space programs to
    decide that; but it probably doesn't matter much either way.
    
    As a work-around for this problem (at least on Red Hat 6.2), you can
    chmod the files manually (assuming they already exist with the wrong
    permissions), and set the umask to 022 in /etc/rc.d/rc.sysinit.  That
    should be the only place you really need to set the umask.  Or, if you
    really want to make sure this is your system default (i.e. that all
    start-up scripts run with this UMASK value), you should be able to set
    the umask in /etc/initscript (I haven't tried it).
    
    -- 
    ---------------------------------------------------
    Derek Martin          |   Unix/Linux geek
    ddmat_private    |   GnuPG Key ID: 0x81CFE75D
    Retrieve my public key at http://pgp.mit.edu
    
    
    
    



    This archive was generated by hypermail 2b30 : Tue Jul 17 2001 - 15:21:40 PDT