Message-ID: <20070222131407.GA10818@grok.org.uk>
Date: Thu, 22 Feb 2007 13:14:07 +0000
From: John Cartwright <johnc@...k.org.uk>
To: full-disclosure@...ts.grok.org.uk
Subject: Fwd: [full disclosure] Linux generic devices /
	pam.console problem

Hi

I was asked to forward this to the list...

Cheers
- John

[full disclosure] Linux generic devices / pam.console problem

josc-vulnerability@...or.de, 5.2.2007
modified +details disclosed 21.2.2007

May be distributed without charge for the purpose of alerting people.
I hope the information will be useful, but it COMES WITHOUT ANY WARRANTY.
I am not perfect - acting on this FREE information will be YOUR RISK.
Not all Linux systems are set up the same way -- please use your brain.


SECURITY ALERT

Linux security problem related to SCSI generic devices / PAM Console


IMPACT

UNAUTHORIZED ACCESS to SCSI DEVICES for LOCAL USERS
 (they can access SCSI devices they really should not)

"SCSI devices" includes BOTH real SCSI devices (this has been tested)
and fake ones (tested with a usb-storage digicam) like
external USB harddisks, USB sticks, probably "ide-scsi" device nodes, etc

The road to PRIVILEGE ESCALATION is unfortunately painfully obvious.
Perfect example: SCSI harddisk with / on it.


DETAILS/AFFECTED SYSTEMS

A vulnerability has been spotted on some Linux systems. The vulnerability
is related to "SCSI generic devices" which are handled by the "sg" kernel
driver.

Some systems are set up to have PAM console give all those devices
to local users upon console login. This is a bad thing.

This is NOT a theoretical threat only.

FULL ACCESS HAS BEEN SUCCESSFULLY PERFORMED on a machine running Linux
2.4.33 and on a system booted from a quite recent "LiveCD" with 2.6.x
kernel. Unsystematic field research shows other systems may be vulnerable,
too, while others (hopefully) seem to be not.

"Rack" machines (web servers, CPU farms, shell servers) should be
locked down anyway and permit no access to SCSI generic devices at all.
(Warning: Some installations "generate" device nodes on lookup.)

It looks like the more "DESKTOP-ish" your machine is, the more likely
it is to be affected. (Users do not generally log in at the console on
rack machines.)

Note: It is customary that "console login" means "physically sitting
at the console and logging in". In some configurations, this may have
been changed to include remote logins (e.g. to the "box with CD-burner in the
corner"). A questionable idea or not - such configurations obviously
extend the risk to remote logins.

Note: Since those devices are given to the user, it is actually
not necessary for an attacker to sit at the box, just to 0wn the user-ID
of the console user who is actually logged in.

The vulnerability was spotted on a machine running a dated Mandrake
version with kernel 2.4.33. The PAM package is pam-0.77-12mdk.
A recent Mandriva PAM package was downloaded,
pam-0.99.6.3-1mdv2007.1.i586.rpm. The problem seems to persist there
but this was not tested on a living system.

A recent 2.6 kernel "Metisse" Mandriva Live-CD was downloaded and tried:
new user added, new user logged in at the console and got the
generic devices handed to him. This meant full, read-write access.
Yes, tested with a real SCSI /dev/sda harddisk, too.
*Without* logging in at the console, those devices were found to belong
to group "cdwriter" which had the only user "saned" in it. I would
not recommend this either, but more poking has not been done.

A recent Ubuntu Live-CD was also tested and (no guarantees here)
that particular problem could not be reproduced. That does not
mean I recommend that system (try "man sudo_root" on Ubuntu).

According to indirect reports and google research, the
problem is probably present in other Linux distributions too, at
least in older releases. It may actually be admin error in some
installations ("here, cool trick for getting cdrecord working")

Note: Generic devices have been prone to security problems in the past.
This seems to be a different problem than the one fixed by
allow_dio, at least "cat /proc/scsi/sg/allow_dio" yields 0 and the
problem persists.


HOTFIX

Denying any access for non-root users to the "sg" driver seems
to block the vulnerability from being exploited.
This will break a lot of things; if you have no important or
privilege-escalating data on SCSI devices,
you may actually think twice about whether to apply this at all. However,
generic SCSI has been a nightmare in the past and will probably continue to
be, thus a strategy of "phasing out" those devices entirely
seems not to be unreasonable.


Some ways might be (your mileage may vary though):

0 If your machine is one of the rack boxes mentioned above, is properly
  locked down and you are REALLY sure users cannot access generic devices
  at all (or you REALLY DO KNOW what you are doing), no further action
  should be necessary (I *hope*). If you do not need the sg driver, it
  would probably not hurt to disable it by one of the methods listed
  below.

1 If your kernel has a modularized sg driver,
  locate the sg module, rmmod it if necessary, rename/move
  it. Traditionally under 2.4.x, modules live under /lib/modules/x.y.z/,
  where x.y.z is your kernel version. Ensure the module cannot be loaded
  or autoloaded at all. Do not allow non-root users to load modules.
  Caution: A kernel build and make modules_install (or similar actions) will
  of course restore the module.

2 A kernel rebuild with the driver configured out. Reboot with new kernel.
  No way to load other kernels.

Note: 1 and 2 will obviously disable access to generic SCSI devices, even
  for root. This will break lots of things, like SCSI CD burning, using some
  scanners, etc. even for root.

3 For most 2.4.x systems with a /dev/scsi tree:
  Change the access rights on the /dev/scsi directory: ensure that
  non-root users cannot access that directory tree. /dev/scsi should
  belong to root anyway. "chmod 700 /dev/scsi" should achieve that
  non-root users cannot open SCSI devices at all
  (provided that is the only place with SCSI device nodes).

  CAUTION: Do NOT attempt to adjust device permissions manually.
  Modern Linux systems have a "dynamic" /dev directory, meaning the system
  knows everything better than you and WILL sabotage your attempts.
  Whether the permissions on /dev/scsi are retained seems to depend on
  configuration, on my test box they did survive a reboot. You may want
  to reboot anyway if you suspect your users to have grabbed open
  descriptors.

Note: 3 will break all access to ALL SCSI device nodes for non-root users.
  Among other things, this means no recording CD-Rs via SCSI, no
  mounting SCSI partitions, no access to scanners driven via "sg",
  etc., as non-root.


FIXING THE ACTUAL PROBLEM

The PAM console configuration must be repaired. Depending on installation,
it lives in /etc/security/console.perms or in subdirectories of
/etc/security (newer versions), or somewhere (who knows). Since the
fix depends on installation I will just give some problems to watch
out for, no step-by-step fix:

- The problem looks like this:

   <burner>=/dev/scd* /dev/sg* /dev/pcd* /dev/pg* /dev/cdwriter
                                      /dev/scsi/*/*/*/*/generic


- It will not help to delete the "generic" entry only, the rest
  of the defective line can ruin your system
  too. Example: the /dev/sg* symlinks commonly point to the generic
  devices, and yes, symlinks were followed when I did the tests.
  (On 2.6 they are not even symlinks)
- Trying to specify "<burner>=" (empty set)  is a nice idea - too bad devfsd
  coredumped when I tried this. If you comment out the line
  entirely, also locate the corresponding permission line below
  and comment it out, otherwise devfsd complains and goes on strike.
- obviously you will have to make the device demon reload its config


CONTACT INFORMATION

Please do not e-mail me if it is not really important. Linux has a really
large user base. Discussing the problem should be done in public.


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists