Re: [ Hackerslab bug_paper ] HP-UX crontab temporary file symboliclink vulnerability

[Robert Watson <rwatson () FREEBSD ORG>]

On Tue, 24 Oct 2000, Sergey Nenashev wrote:

> Tested on
> 4.0-RELEASE FreeBSD 4.0-RELEASE #9
> 4.1-RELEASE FreeBSD 4.1-RELEASE #1:
>
> Can read any file wich start with comment simbol (#)

The following was determined on a 4.1-STABLE box and a 3.5-STABLE box, and
should probably be confirmed on the production releases, although I have
no reason to doubt that what I'm about to say is true for the two releases
identified.

At least on our version of Vixie Cron, this description appears to be
inaccurate on an initial inspection.  Yes, there is a bug, and a serious
one, but the syntax requirements are much stronger than those that are
described above: the file must fully conform to a valid crontab file
specification.  I.e., the sample sudoers file included in the paper will
not work in FreeBSD as it violates crontab formatting specifications; this
substantially limits the impact of this bug for the purposes of acquiring
additional privilege.  Off-hand, here are some things that are *not*
readable due to standard formatting of the files:

  /etc/ssh/ssh_host_key
  /etc/ssh/ssh_dsa_host_key
  /etc/ssl/mykey.prv
  /tmp/ssh-GbQ60456/cookies
  /etc/master.passwd
  /etc/spwd.db
  /home/rwatson/.ssh/identity
  /home/rwatson/.netscape/preferences.js
  /home/rwatson/.pgp/secring.skr
  /home/tkt1000

Here are some things that are readable:

  /var/cron/tabs/arbitraryuser
  Files that are entirely commented using '#', optionally with blank lines
  Binary files that start with a # and contain no linefeeds
  Empty files

So in the situations that I have investigated thus far, this cannot be
leveraged to gain additional privielge in a plain vanilla FreeBSD system,
as private keying material in the base system typically requires a tightly
formatted key storage file that necessarily precludes valid crontab file
formatting.  It can be use to extract any keying material from crontab
command lines of other users, but users should not be storing stuff there
anyway as generally that can be extracted using ps.  It can be used to
read entirely #'d files which could be an issue in some configurations:
for example, if the administrator added shared secrets to
/etc/ppp/ppp.conf and then commented out the entire file.

So I would guess that in the base system, this admittedly serious bug buys
the attacker little; some third party applications might be exploitable if
they rely on files that meet these formatting constraints to store
sensitive information.  Hopefully we'll get fixes into the base tree and
release an advisory shortly.  If anyone can get any further in exploiting
this bug, please contact security-officer () FreeBSD org, which is a good
first stop for any notifications about security holes you might find.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
robert () fledge watson org      NAI Labs, Safeport Network Services