Mitigating against recent GNU/Linux kernel bugs

Posted by Steve on Sat 15 Jul 2006 at 10:12

Recently the Debian project was compromised after a user account was escalated to root via a bug in GNU/Linux kernel. This bug doesn't affect the Sarge kernel(s), but it might affect you if you're running a different distribution. Here we'll cover a couple of hot-fixes.

The bug which was used abused the prctl system call. This essentially allows a local attacker to write core files to arbitary directories.

In the public attacks this has been used to create a corefile in directories such as /etc/cron.d which cron will intepret and accept. (Arguably a bug in cron...).

To prevent this attack you can make use of a couple of Kernel parameters which are designed to disable corefiles, or move them to a single fixed directory. As root run:


echo 0         >/proc/sys/kernel/core_uses_pid
echo /dev/null >/proc/sys/kernel/core_pattern

(This change can be made persistent via the /etc/sysctl.conf file.)

Together this should prevent you from falling victim to this attack.

Unfortunately another bug which also allows a local user to gain root has surfaced rather publically. This new attack takes advantage of the /proc filesystem.

To prevent this new attack the following should be sufficient:

mount -o remount,noexec,nosuid /proc

Update your /etc/fstab to make the change persistent.

 

 


Posted by simonw (84.45.xx.xx) on Sat 15 Jul 2006 at 11:41
[ View Weblogs ]
Is there any reason that "nosuid" shouldn't become the default for all Debian (Linux versions anyway) /proc mounts?

[ Parent | Reply to this comment ]

Posted by Steve (62.30.xx.xx) on Sat 15 Jul 2006 at 11:58
[ View Steve's Scratchpad | View Weblogs ]

Just a historical accident that nobody has noticed/cared enough about to change I think.

A new bug was filed about this already, so hopefully in the future things will be better: #378280.

Steve

[ Parent | Reply to this comment ]

Posted by simonw (212.24.xx.xx) on Mon 17 Jul 2006 at 10:58
[ View Weblogs ]
Whilst we are caring about these things...

$mount
proc on /proc type proc (rw,noexec,nosuid)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
usbfs on /proc/bus/usb type usbfs (rw)
...


Okay "proc" needs to be "rw" for some things.

File systems mounted "user" or "users" get "nosuid, noexec, nodev".

NFS also exercises a certain amount of "self defence" automatically, although using NFS is pretty much death to security in most environments still.

Can I add "nodev" to proc safely?

sysfs, devpts, tmpfs and usbfs are not explicitly mentioned in "/etc/fstab", and there are some warning around the web about trying to mount sysfs automatically on 2.4 kernels (since it only exists in 2.6). The Debian hardening guide focuses on user filesystems, presumably the kernel created ones should do the "right thing" at the kernel layer and pick their own minimal settings correctly?! (I'd hate to reassign a bug to the wrong team, but I think it is one for Linus and friends, automatic files systems show not allow themselves to have too much privilege, shouldn't be fixed by the system administrator -- like shipping a car with a sign "please attach brakes after delivery" -- especially as the kernel team might decide device files in "/proc" are a good idea, and could then fix it without changing a million /etc/fstab files).

The Debian hardening guide also seems to suggest that some of the options mentioned are "ext2" specific, when I think they are more general, or perhaps I am misreading it.

First bullet point in section 4.9, I'm unclear as to scope.
http://www.debian.org/doc/manuals/securing-debian-howto/ch4.en.ht ml#s4.9
It also makes the options that kick in with "user"/"users" explicit, probably no harm in that, coding the defaults is good, but might have been handy to mention they are the defaults (or that some of them maybe defaults but we put them in anyway).

Making "/tmp" an explicit filesystem would seem like the smart move. Although I suspect we abuse /tmp for executable files in house, at least I wouldn't like to say we don't.

[ Parent | Reply to this comment ]

Posted by Anonymous (66.36.xx.xx) on Sat 15 Jul 2006 at 17:22
I believe these are both fixed in version 2.6.17.5, which I've just installed now.

[ Parent | Reply to this comment ]

Posted by Anonymous (83.130.xx.xx) on Sat 15 Jul 2006 at 21:45
can you please be more specific about the required change to /etc/sysctl.conf ?

[ Parent | Reply to this comment ]

Posted by Steve (62.30.xx.xx) on Sat 15 Jul 2006 at 21:52
[ View Steve's Scratchpad | View Weblogs ]

Sure. Update your /etc/sysctl.conf file to include:

kernel/core_uses_pid=0
kernel/core_pattern=/dev/null

Then to load all those values run "sysctl -p".

(All these values will be loaded automatically when your system boots, via the init script /etc/init.d/procps.sh.)

Steve

[ Parent | Reply to this comment ]

Posted by rjc (87.74.xx.xx) on Tue 18 Jul 2006 at 20:42
Just one small thing to add, if you're using unstable there should be dots '.' instead of slashes '/' in /etc/sysctl.conf

rjc

[ Parent | Reply to this comment ]

Posted by ptecza (83.16.xx.xx) on Sun 16 Jul 2006 at 20:09
Why Debian project machines don't run Sarge kernel(s)?

P.

[ Parent | Reply to this comment ]

Posted by Steve (62.30.xx.xx) on Sun 16 Jul 2006 at 20:17
[ View Steve's Scratchpad | View Weblogs ]

Hardware support, apparently.

Steve

[ Parent | Reply to this comment ]

Posted by ptecza (83.16.xx.xx) on Sun 16 Jul 2006 at 20:34
It must be testing or unstable hardware ;)

P.

[ Parent | Reply to this comment ]

Sign In

Username:

Password:

[Register|Advanced]

 

Flattr

 

Current Poll

What do you use for configuration management?








( 336 votes ~ 1 comments )

 

 

Related Links