Vulnerability

    audlinks

Affected

    Solaris

Description

    Optyx  found  following.   /usr/sbin/audlinks  has  the  following
    behavior:

        $ id
        uid=100(optyx) gid=1(other)
        $ mkdir -p /tmp/b/dev
        $ ln -s /.rhosts /tmp/b/dev/.devfsadm_dev.lock
        $ su root
        Password:
        # /usr/sbin/audlinks -r /tmp/b
        # ls -l /.rhosts
        -rw-r--r--   1 root     other          4 Dec 28 14:28 /.rhosts

    truss output snippet:

        open("/dev/.devfsadm_dev.lock", O_RDWR|O_CREAT, 0644) = 4

    This  is  similar  to   the  /usr/sbin/patchadd  file   clobbering
    "vulnerability" (not really a vulnerability  as a user has to  set
    the link then root has to run the program, but).

    '//Stany'  added  following.   audlinks  and  a  number  of  other
    programs  (/usr/sbin/drvconfig  /usr/sbin/devlinks /usr/sbin/disks
    /usr/sbin/ports         /usr/sbin/tapes         /usr/sbin/audlinks
    /usr/ucb/ucblinks)   are   most    commonly   run   through    the
    /etc/init.d/drvconfig  and  /etc/init.d/devlinks  startup scripts,
    or  potential  symlinks  to  those  scripts  from  the /etc/rc*.d/
    directories.

    Generally both /etc/rcS.d/S50drvconfig and  /etc/rcS.d/S60devlinks
    get run on  boot-up.  However  the first thing  the scripts do  is
    check  that  $_INIT_RECONFIG  is  not  empty  (set  by /etc/rcS if
    /reconfigure is present on boot-up,  or if -r argument to  init is
    given on  bootup: ok  boot -r),  and if  it is  empty, the  script
    aborts right there.

    If  the  $_INIT_RECONFIG  is  not  empty,  the  scripts  get  run,
    executing files in /usr/sbin/ in the above order.

    The purpose of  these files is  to probe the  hardware detected by
    the kernel, and to populate  the /dev with the proper  symlinks to
    /devices.

    As these scripts are generally  run on boot-up only (although  ppl
    run #  drvconfig &&  devlinks &&  disks &&  ucblinks whenever they
    have to hot-swap a hard drive  or a CD-Rom drive), and on  boot-up
    Solaris comes  up with  a clean  /tmp if  /tmp is  set up as tmpfs
    (default), the vulernability is not as big as it could have  been.
    Also, as hardware changes is not that common an occurance in  many
    systems, exploiting  something like  that would  not be  that easy
    (On  Sun  systems,  audio  hardware  is  generally  built into the
    motherboard [Except maybe something like SS10 or SS2, where if  an
    external  speakerbox  is  not  detected,  audio  devices  are  not
    created], so there is  no reason to run  audlinks by hand.   In an
    x86 system, the audio  devices can be a  PCI or an ISA  board, but
    one has to ether have  hotswappable PCI [Are there even  a hotswap
    PCI soundcards?], or an ISA  board, and most people would  want to
    shut the system down to add PCI or ISA device to the x86  system),
    The impact of this vulnerability is minimal.  However this doesn't
    mean that it should not be fixed.

Solution

    Wait for patch from Sun.