Kees Cook of Ubuntu informed us that there is a nasty local root exploit that was discovered with udev recently. It appears that upgrading to sys-fs/udev-141 and rebooting should fix the problem. There is no public exploit yet but Kees suggests that it shouldn't take a skilled attacker long to write one up. Here is the text from the link referenced: Sebastian Krahmer discovered that udev did not correctly validate netlink message senders. A local attacker could send specially crafted messages to udev in order to gain root privileges. (CVE-2009-1185) Sebastian Krahmer discovered a buffer overflow in the path encoding routines in udev. A local attacker could exploit this to crash udev, leading to a denial of service. (CVE-2009-1186) Reproducible: Always
Tweaking summary as udev-141 seems to be not affected.
Maintainers, what are the stabilization plans for 141?
For now latest stable is udev-124-r1 as you can see. There is a stable request for udev-135-r4 open, but this one is blocked by some ugly dependency of cryptsetup. The stable cryptsetup directly calls udevsettle (which it nevertheless should not do), but this makes cryptsetup depend on old udev. Some new ~arch cryptsetup has this fixed but has other bugs, and they do not consider backporting the applied patch to stable and make a new revision to finally allow udev to move forward. So before this is solved we also cannot stable udev-141, besides this version is only 6 days in tree. From looking at the descriptions it should be these two commits fixing the respective issues: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=662c3110803bd8c1aedacc36788e6fd028944314 http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=e86a923d508c2aed371cdd958ce82489cf2ab615 So maybe it is possible to backport them, but I have not checked yet.
Created attachment 188500 [details, diff] udev-124.patch Ubuntu backport of the patch. Please apply to our stable.
Adjusting severity according to whiteboard.
Added the two backported patches from ubuntu and made a ~arch udev-124-r2 ebuild to bet tested and stabled.
Arches, please test and mark stable: =sys-fs/udev-124-r2 Target keywords : "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86"
A question, as udev is a daemon (but not something one can just restart), how would one go forward on an already running system? Is there a way to get the fix running without rebooting? Something that should probably be mentioned in the advisory.
(In reply to comment #8) > A question, as udev is a daemon (but not something one can just restart), how > would one go forward on an already running system? > > Is there a way to get the fix running without rebooting? > > Something that should probably be mentioned in the advisory. > If you have a look at the udev ebuild: There udevd is restarted in pkg_postinst
My additional plan is to remove all newer ~arch versions that are affected: udev-{122-r1,125-r2,130-r1,133,135,135-r1,135-r2,135-r3,135-r4,138,139,140}.ebuild Any vetos? That will leave us just with udev-141 that can play with openrc.
(In reply to comment #10) > My additional plan is to remove all newer ~arch versions that are affected: > udev-{122-r1,125-r2,130-r1,133,135,135-r1,135-r2,135-r3,135-r4,138,139,140}.ebuild > > Any vetos? Please go ahead. Also, arches. please note this is a high priority stabling.
CVE-2009-1185 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-1185): udev before 1.4.1 does not verify whether a NETLINK message originates from kernel space, which allows local users to gain privileges by sending a NETLINK message from user space. CVE-2009-1186 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-1186): Buffer overflow in the util_path_encode function in udev/lib/libudev-util.c in udev before 1.4.1 allows local users to cause a denial of service (service outage) via vectors that trigger a call with crafted arguments.
Stable for HPPA.
18 Apr 2009; Tobias Heinlein (keytoaster) udev-124-r2.ebuild: amd64 stable wrt security bug #266290
x86 stable
ppc64 done
ppc done
arm/ia64/m68k/s390/sh/sparc stable
Stable on alpha.
GLSA already filed, pending one approval.
GLSA 200904-18, thanks everyone for the quick reaction.
