LWN: Comments on "A privilege escalation flaw in udev"

A privilege escalation flaw in udev

smithj — Fri, 24 Apr 2009 18:43:47 +0000

FYI, I updated udev only on various RHEL5 boxen from 5.1 to 5.3, with weird patch levels in-between. I've yet to see any problems.

Your milage may vary.

A privilege escalation flaw in udev

nix — Fri, 24 Apr 2009 10:37:38 +0000

It can be tricky to get LVM aligned properly for LVM-atop-RAID, and if you
get it wrong you get a silent substantial slowdown...

(RAID-atop-LVM is not prone to this because you don't get the same excess
RMW cycles.)

A privilege escalation flaw in udev

jimparis — Thu, 23 Apr 2009 17:08:55 +0000

That is not true. Go look at Kay's commit. It adds the SO_PASSCRED option to the socket and adds an explicit check for (cred->uid != 0). As the LWN writeup indicated, 'either patch "alone would be sufficient" to fix the problem'. And your statement about him being quick to notify others is misleading at best. There has still not been a single posting on the udev mailing list about this problem!

A privilege escalation flaw in udev

janfrode — Thu, 23 Apr 2009 16:07:20 +0000

And just to be on the paranoid safe side I asked Red Hat support, and they confirmed it should be safe to upgrade on any RHEL5 update levels.

A privilege escalation flaw in udev

Tet — Thu, 23 Apr 2009 15:24:40 +0000

I'd say LVM fixed that inconvenience long ago, and the benefits of multiple filesystems are still there. I can't really understand why anyone would go with a single large root filesystem.

A privilege escalation flaw in udev

BenHutchings — Thu, 23 Apr 2009 14:12:54 +0000

No, that commit does what it says. The commit that fixed this bug was made by Scott James Remnant and has the subject "libudev: monitor - ignore messages from unusual sources". This is not entirely explicit, but it may not have immediately occurred to him that this was a severe security flaw. I can say that he was fairly quick to notify others about it.

A privilege escalation flaw in udev

nix — Thu, 23 Apr 2009 13:56:08 +0000

This looks like a reason why a /sys/block entry containing a device node for each device rather than just a textual representation of (major, minor) might be useful: but that was already rejected :/

A privilege escalation flaw in udev

Ross — Thu, 23 Apr 2009 13:52:01 +0000

It's useful for chroot()ed filesystems or to fix /dev problems from another installation by mounting
under /mnt or wherever. The kernel shouldn't "know" that /dev is special.

I believe that installers also create these files in /tmp if you want another example.

A privilege escalation flaw in udev

cesarb — Thu, 23 Apr 2009 13:25:45 +0000

I have seen that sentence in every single security advisory they issue, so it is probably just a boilerplate sentence (of course, one can expect there are reasons for them adding that boilerplate).

A privilege escalation flaw in udev

etienne_lorrain@yahoo.fr — Thu, 23 Apr 2009 11:52:08 +0000

> Can anyone think of a reason why mknod() allows *anyone*
> to create device nodes outside /dev?

How would you ask ioctl like BLKBSZGET, BLKSSZGET, BLKGETSIZE,
BLKGETSIZE64, HDIO_GETGEO_BIG, to the file system which contains
a file given as parameter?
As an example:
http://www.mirrorservice.org/sites/download.sourceforge.n...

There is maybe a better solution (without having to guess the mount
point *name*) - I am listening...

A privilege escalation flaw in udev

kaber — Thu, 23 Apr 2009 11:10:32 +0000

A few minor notes on netlink and this bug:

- netlink supports 2^32-1 groups in recent kernel versions

- the proper way to check that a message is from the kernel is to check for a PID of zero. Its also worth noting that netlink PIDs are just numerical identifiers with a badly chosen name, they have no direct relationship to process PIDs.

- regarding other netlink users: the exactly same bug was present in iproute and IIRC the *swan keying daemons a couple of years ago. I'd expect it to be present in more software using netlink.

Netlink for userspace to userspace communication seems like a pretty useless feature, unfortunately we can't remove it or require receiving processes to optionally enable it for compatibility reasons.

A privilege escalation flaw in udev

janfrode — Thu, 23 Apr 2009 08:45:02 +0000

The Red Hat errata for this fix says:

Before applying this update, make sure that all previously-released
errata relevant to your system have been applied.

Is that just the normal cop out, or are there any reasons to worry upgrading udev on a RHEL5u0 will break something.. ?

A privilege escalation flaw in udev

jimparis — Thu, 23 Apr 2009 07:09:49 +0000

Kay's commit message is:
"libudev: monitor - unify socket message handling"

It would be nice to at least hint at the fact that this fixes a critical security flaw... the release notes for udev 141 didn't even suggest that there was any reason to upgrade: http://lwn.net/Articles/328340/

That's pathetic.

reboot?

jabby — Thu, 23 Apr 2009 07:03:51 +0000

so, no reboot is necessary for the kernel to use the new udev?

A privilege escalation flaw in udev

smithj — Thu, 23 Apr 2009 00:42:46 +0000

The RHEL update for this issue automatically restarts udev. I would imagine other vendors either do the same or that /etc/init.d/udev restart (or similar) would be safe to execute on an in-production system.

A privilege escalation flaw in udev

dlang — Thu, 23 Apr 2009 00:39:14 +0000

there is a mount option to deny the ability to use device nodes on a filesystem, but it's seldom used nowdays (the benifit from splitting up the filesystem into many slices is outweighed by the inconvienience of dealing with the many slices)

A privilege escalation flaw in udev

jreiser — Thu, 23 Apr 2009 00:05:31 +0000

Can anyone think of a reason why mknod() allows *anyone* to create device nodes outside /dev?

Before there was kernel-level virtualization (vmware, xen, kvm, ...) there were partial virtualization environments which needed devices. If you have a machine with trusted users only and/or global protection, then mknod() can be handy for experiments.

A privilege escalation flaw in udev

nix — Wed, 22 Apr 2009 22:40:53 +0000

Can anyone think of a reason why mknod() allows *anyone* to create device
nodes outside /dev? (Or, more generally, why isn't a special mount option
required to create device nodes on a filesystem? The ability to create
device nodes absolutely anywhere is a 'feature' of Unix that I've never
seen be of actual use to anyone except attackers.)

This would have fixed the NFS problem, at least, although not the udev
hole (as udev would have created the node in /dev, which would have had
that flag...)

(More evilly still, if you indicate this in the superblock and have it be
set at mkfs time --- also not problematic for your average system with a
tmpfs /dev --- this lets us recycle the now-unused st_rdev field in the
inode for something else. Not a huge saving, true, but it *is* a saving,
and there are a *lot* of inodes on your average system.)

A privilege escalation flaw in udev

Trou.fr — Wed, 22 Apr 2009 22:29:45 +0000

The most clever way to exploit this vulnerability is to leverage the fact that since udev 116, it is possible to specify a command to be run in the message sent via the netlink socket.

So on udev > 116, you have arbitrary command execution as root, for any users, 100% reliable, not arch specific.

One of the most important vulnerabilities in years on GNU/Linux systems imho.

A privilege escalation flaw in udev

arjan — Wed, 22 Apr 2009 21:46:46 +0000

yes but it does that in a tiny database in /dev ... so persistent between udev restarts...

A privilege escalation flaw in udev

jengelh — Wed, 22 Apr 2009 21:12:23 +0000

Maybe, but none that I know would be relevant to interruption like upgrade.

A privilege escalation flaw in udev

pranith — Wed, 22 Apr 2009 19:16:36 +0000

doesnt udevd keep track of all the devices it created??

A privilege escalation flaw in udev

proski — Wed, 22 Apr 2009 18:28:16 +0000

Upgrading udev should not cause any downtime.

A privilege escalation flaw in udev

tzafrir — Wed, 22 Apr 2009 18:25:53 +0000

Kill udevd :-(

On a server system it should work.

A privilege escalation flaw in udev

pheldens — Wed, 22 Apr 2009 18:05:53 +0000

Is there a quick fix to fix a running system without downtime?

rootness checking

sladen — Wed, 22 Apr 2009 15:22:42 +0000

Linux-Vserver container instances are a case where uid=0 is root, possibly CAP_NET_ADMIN, but not CAP_SYS_ADMIN.