linux security - Apr 1998 - New hack against BSD, Linux is _mostly_ safe from it.

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

> 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
Well, if not bootable kernel, lilo without any access restriction can run 
any program as init e.g 

	linux init=/bin/sh rw

will give you root shell.

Regards,
Yusuf

-----------------------------------------------------------------------
Yusuf Motiwala		Hughes Software Systems, 0124-346 666 ext. 2298
http://ulf.wep.net, 
http://yusuf.home.ml.org

On Mon, 13 Apr 1998 sinster@darkwater.com wrote:
> Date: Mon, 13 Apr 1998 14:43:33 -0700 (PDT)
> From: sinster@darkwater.com
> Reply-To: linux-security@redhat.com
> To: linux-security@redhat.com
> Cc: sinster@darkwater.com
> Subject: [linux-security] New hack against BSD, Linux is _mostly_ safe from
it.
> Resent-Date: 14 Apr 1998 06:03:45 -0000
> Resent-From: linux-security@redhat.com
> Resent-cc: recipient list not shown: ;
> 
> 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 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
> 
> -- 
> ----------------------------------------------------------------------
> Please refer to the information about this list as well as general
> information about Linux security at http://www.aoy.com/Linux/Security.
> ----------------------------------------------------------------------
> 
> To unsubscribe: mail -s unsubscribe test-list-request@redhat.com <
/dev/null
> 
>

In article <6gv2a3$vkk$1@vulcan.alphanet.ch> you
wrote:
> Linux booted from LILO is not vulnerable, because bootable kernels must
put a floppy with the kernel
lilo: linux root=/dev/hda1 [where the root fs lies]

this causes the system to boot with the new kernel.

Note that you can also simply mount the root fs from a floppy.

This type of attack is possible (and many others) if you have
access to the console and a floppy drive.

Put a password on the BIOS, disable diskette booting, lock the
PC box so that noone can reset the CMOS, install Lilo so that
it does not accept user prompt anymore, and hope your BIOS
has no hidden passwords or side-effects.

> 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.
SILO can load an arbitrary kernel (it understands the ext2 filesystem).
I don''t consider this a "security hole" since if you can get
access to
SILO or the PROM you can do a whole myriad of other nasty things (like
''linux single'' from SILO or from the PROM you can just boot a
CD or
floppy or even a network image).

Yes, this is a security "issue", but it is not a "hole" per
se.


--Donnie


--
 Donnie Barnes    http://www.redhat.com/~djb    djb@redhat.com  
"Bah."
   Challenge Diversity.  Ignore People.  Live Life.  Use Linux.  879.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
_Things You''d NEVER Expect A Southerner To Say_ by Vic Henley:     
**  We don''t keep firearms in this house.

A number of people (4) have replied to me saying that this hack I''ve
mentioned isn''t particularly interesting because physical access allows
an attacker to use a boot floppy.

But that''s entirely missing the point: this attack requires no boot
medium at all.  In fact, I specifically mentioned that in my original
message.  This minor detail becomes important because there are a large
number of machines around the world where physical access to the console
is trivial for the general public, but access to the machine itself for
purposes of disassembly or insterting a floppy is difficult or impossible.
Two classic examples of such machines are internet cafes (where the machine
is padlocked into a steel enclosure that provides access only to the power,
video, and keyboard cables), or in university computer labs (where the
machine is accessible, but a watchful attendent is keeping an eye on the
relatively small number of machines present).

While none of these machines are likely to contain information that is
sufficiently interesting for an attacker, root access to these types of
machines is useful in itself because it provides a good way to stop
any audit trail of an attack.

(As Ted T''so discovered while trying to email me from MIT, I put a lot
of value in the accuracy and usefulness of my system logs).

[mod: Lets put this (definitively NOT NEW) issue to rest ok? Summary:
It is hard, if not impossible to secure a machine that you allow
physical access to. Make sure you set passwords on the BIOS and LILO
if your adversaries are not opening the box, or if you''ve locked the
box. BIOS passwords are most likely uneffective, as many BIOS
manufacturers have provided for backdoors.  -- REW]

-- 
Jon Paul Nollmann ne'' Darren Senn                    
sinster@darkwater.com
Unsolicited commercial email will be archived at $1/byte/day.
"I believe there are more instances of the abridgement of the freedom of
the
people by gradual and silent encroachment of those in power than by violent
and sudden usurpations."   James Madison, speech, Virginia Convention, 1788