Re: /usr/sbin/audlinks vulnerability

[//Stany <stany () NOTBSD ORG>]

On Thu, 28 Dec 2000 Optyx - Uberhax0r Communications () SECURITYFOCUS COM wrote:

A couple of words about audlinks, as there is no man page for it (at least
on my installation of Solaris 2.6 5/98 SPARC)

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 I run
# drvconfig && devlinks && disks && ucblinks
whenever I 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), I'd
argue that the impact of this vulnerability is minimal.  However this
doesn't mean that it should not be fixed.

I did a quick find on the Solaris(TM) 8 English, Source Foundation
Release, Sparc/Intel Binary CD that I am a licensee of, but it seems like
Sun did not provide the source to audlinks on it, so guess we'll have to
wait for a patch from Sun.

stany@dara:/raid1/sol8[140]$ ls
Copyright                     i386                          source_product_documentation
admin_cd0                     osnet_volume                  sparc
stany@gilva:/raid1/sol8[141]$ find . -name "*audlinks*" -print
stany@gilva:/raid1/sol8[142]$




> /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)
>
> -Optyx, Uberhax0r Communications
> http://www.uberhax0r.net

Signed:
//Stany
--
+-------+ Stanislav N Vardomskiy - Procurator Odiosus Ex Infernis[TM] +-------+
| "Backups we have; it's restores that we find tricky." Richard Letts at ASR  |
| This message is powered by JOLT!  For all the sugar and twice the caffeine. |
+--------+ My words are my own.  LARTs are provided free of charge. +---------+