Linux libc5.4.33''s mk[s]temp() functions require 6 X''s at the
end of
a filename (the BSD versions I''ve seen are a bit more flexible). This
alone
is enough to break any claims to real BSD compatability, but wait,
there''s
more:
Only 1 of those 6 X''s are really unique. The rest are simply pid.
So you can create exactly 62 temp files using mk[s]temp() in one pid. When
using mkstemp(), a EEXIST error is returned, and you get no fd, so
you''re
unlikely to do anything dumb, so it''s just a really annoying DoS. When
using mktemp(), an error is also returned, ENOENT (why not EEXIST?). I was
naive when coding my program that used mktemp(), so I didn''t check the
return value (the string was modified to the filename of the most recently
created temp file, so it seemed as if the call had succeeded, I just
didn''t
get a unique filename)...what''re the odds of something like 10^6
(assuming
it only uses digits) temp files showing up in ~root/mail/, right?
The best way I can think of to handle this situation is to cause the
X''s to be 3 bytes (represented in hex) of an unsigned int that is
initialized using the getpid()+time() or something and just incremented
(making it static to avoid unnecessary tests...I don''t know what this
does
to threadsafeness). That way you get 16^6 temp files, more than enough,
given that I have fewer than 100,000 inodes in use on my whole drive.
As usual, good programming practices (checking your return values)
saves you from the security problems, but allows the DoS to continue.
Judging by past behavior from the glibc2/libc6 team, if the problem exists
there (I haven''t checked...it''s a big download),
it''ll probably get fixed
soon enough. I apologize for not submitting a libc5 patch -- I don''t
expect
a lot of people to upgrade libc5 versions with libc6 so imminent.
I did test this on BSDI BSD/OS 3.1. BSD/OS seemed a lot more
intelligent (i.e. kept on creating unique filenames) but a /lot/ slower than
I would have expected (only subjectively so).
Greg Alexander - also <gralexan@indiana.edu> - http://sietch.home.ml.org/
----
Don''t ever do anything that you can''t later justify with
"It seemed like a
good idea at the time."
-- Greg''s Bible
From mail@mail.redhat.com Apr 02:04:14 1998 (EDT) -0400
Received: (qmail 12662 invoked from network); 14 Apr 1998 06:03:36 -0000
Received: from ding.yuriev.com (HELO ding.mailhub.com) (207.106.66.2)
by mail2.redhat.com with SMTP; 14 Apr 1998 06:03:36 -0000
Received: (from alex@localhost)
by ding.mailhub.com (8.8.7/8.8.5) id CAA10819;
Tue, 14 Apr 1998 02:04:14 -0400 (EDT)
Received: from mail2.redhat.com (mail2.redhat.com [199.183.24.247])
by ding.mailhub.com (8.8.7/8.8.5) with SMTP id RAA26316
for <alex@yuriev.com>; Mon, 13 Apr 1998 17:45:07 -0400 (EDT)
Received: (qmail 917 invoked by uid 501); 13 Apr 1998 21:44:27 -0000
Received: (qmail 897 invoked from network); 13 Apr 1998 21:44:25 -0000
Received: from scintilla.darkwater.com (206.14.78.190)
by mail2.redhat.com with SMTP; 13 Apr 1998 21:44:25 -0000
Received: from localhost (2810 bytes) by scintilla.darkwater.com
via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
(sender: <sinster>) (ident <sinster> using unix)
id <m0yOr0n-0010KtC@scintilla.darkwater.com>
for <linux-security@redhat.com>; Mon, 13 Apr 1998 14:43:33 -0700 (PDT)
(Smail-3.2.0.96 1997-Jun-2 #4 built 1997-Aug-26)
Message-Id: <m0yOr0n-0010KtC@scintilla.darkwater.com>
Date: Mon, 13 Apr 1998 14:43:33 -0700 (PDT)
To: linux-security@redhat.com
CC: sinster@darkwater.com
Subject: New hack against BSD, Linux is _mostly_ safe from it.
From: sinster@darkwater.com
Approved: alex@yuriev.com
X-FedBait: I''m going to explode a nuclear missile in my bank account.
X-moderate: yes
My housemate has formalized a sortof new attack against unix-style
operating systems. He''s a BSD fan, so that''s where he
developed the
attack. He asked me to check Linux, which I did. It seems Linux is
not vulnerable to it. This attack is going out to BUGTRAQ tonight.
The attack isn''t too serious because it requires physical access to
the console, but it doesn''t require anything like disassembling the
machine. It''s just that you have to type into the boot prompt.
The basic attack is for an unprivileged user to copy the kernel or
otherwise obtain a usable kernel, modify some system call to leverage
root access, and then to make that kernel boot. The BSD bootloader
allows the user to specify any arbitrary pathname to load, so this
attack doesn''t require a boot floppy, or boot CD-ROM, or anything else
of the like.
Linux booted from LILO is not vulnerable, because bootable kernels must
be specified ahead of time in /etc/lilo.conf, and I truly hope that no
Linux system has a publicly writable /etc/lilo.conf. Linux booted from
SILO _is_ vulnerable unless a boot password is specified in /etc/silo.conf,
because SILO will otherwise allow the person at console to specify any
arbitrary file from which to boot, just as the BSD bootloader does. With
the boot password specified in /etc/silo.conf, SILO will require the
user at console to enter the boot password before loading an arbitrary
file.
Someone who is more familiar with SILO than I should take a look at this
to make sure that I''m right: my sparc isn''t working these
days, so I had
to rely on reading the SILO source code to figure out the password
workaround.
The specific hack that''s being posted to BUGTRAQ is in the form of
a gdb script that modifies an existing BSD kernel so that suser() always
returns 0 (which indicates "Yes, he''s a superuser" in the BSD
kernel).
Linux isn''t susceptible to this specific attack because our suser()
function is inlined. Nevertheless, the attack could be modified so
that it changes sys_chmod() to allow anyone to set the setuid flag.
But luckily we''re saved by our bootloaders.
I am not subscribed to linux-security (someone keeps unsubscribing
me), so I have CC-ed myself on this message. If a discussion develops,
please leave me on the CC line so that I can listen in.
Thanks.
--
Jon Paul Nollmann ne'' Darren Senn
sinster@darkwater.com
Unsolicited commercial email will be archived at $1/byte/day.
"Even a fool, when he holdeth his peace, is counted wise." Proverbs
17:28
