Bugzilla – Bug 493158
VUL-0: CVE-2009-1185 CVE-2009-1186: udev local root vulnerability
Last modified: 2017-04-19 13:24:34 UTC
udevd doesnt check nl_pid to equal 0 for KOBJECT_UEVENT messages which allows users to fake such messages, fooling udevd to create mode 0666 block devices or to run network scripts with weird interface names. Additionally there is a overflow in the path encoding: size_t util_path_encode(char *s, size_t len) { char t[(len * 3)+1]; size_t i, j; t[0] = '\0'; for (i = 0, j = 0; s[i] != '\0'; i++) { if (s[i] == '/') { memcpy(&t[j], "\\x2f", 4);//AUD: overflow j += 4; } else if (s[i] == '\\') { memcpy(&t[j], "\\x5c", 4); j += 4; } else { t[j] = s[i]; j++; } } t[j] = '\0'; strncpy(s, t, len); return j; } it should reserve 4 times not 3 times len :)
cc greg, the other udev author ;)
(In reply to comment #0) > udevd doesnt check nl_pid to equal 0 for KOBJECT_UEVENT messages > which allows users to fake such messages How can a normal user send netlink messages on this socket? It should only accept messages from root.
Created attachment 284763 [details] PoC ...
anyone can send netlink messages. for me it doesnt make much sense to send KOBJECT_UEVENT messages from userland either, so call it a kernel weirdness if you like. But any message which has not a pid of 0 in src address struct is from userland. proof of concept exploit attached.
Non-root users can not even listen to the events. Oh, what a very useful kernel feature, that they can send events. :) Thanks!
(In reply to comment #0) > udevd doesnt check nl_pid There is no such field to check, I need to enable credential passing and check these, right? We do the credential check for the unix socket already, and doing the same for netlink should work, right? The changes are here: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=e2b362d9f23d4c63018709ab5f81a02f72b91e75 Thanks, Kay
Created attachment 284932 [details] check sender of netlink message Patch against udev version 128
Assigned CVE-2009-1185 for 'udev doesn't check for origin of NETLINK message' CVE-2009-1186 for 'udev buffer overflow in util_path_encode()' Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Response Team
The SWAMPID for this issue is 23830. Please submit the patch and patchinfo file using this ID. (https://swamp.suse.de/webswamp/wf/23830)
Kay, if SLES 10 SP2 is affected by this problem also roll in the planned updates for sle10sp2. (only if they do not take too long to integrate those bugfix patches) bugs 446534 467217 447995 478132 when everything is submitted for all affected distros, please reassign back to security-team@suse.de and we do the patchinfos and the rest
> roll in the planned updates for sle10sp2 > if they do not take too long to integrate those > bugfixes: > 446534 467217 447995 478132 Hannes, care to prepare the tape rule updates?
multipath-tools is affected from this problem, too.
New udev rpm has been submitted for SLES10.
> multipath-tools is affected from this problem, too. False alarm. We're using the netlink socket only as a fallback when the unix socket provided by udev is not available. Which is on our distribution. So only upstream multipath-tools is affected.
New udev rpms have been submitted for 11.0 and 11.1
New udev rpm has been submitted for 10.3. Done on this end, reassigning.
SLE10-sp2, 10.3, 11.0, 11.1, SLE11, Factory(version update) are all submitted
(In reply to comment #15) > > multipath-tools is affected from this problem, too. > > False alarm. We're using the netlink socket only as a fallback when the unix > socket provided by udev is not available. Which is on our distribution. > So only upstream multipath-tools is affected. It that your code? Do you check credentials on the unix socket? The upstream code, unrelated to the netlink issue, seems to accept any sender on the unix socket that listens to udev.
Update released for: libudev-devel, libudev0, libvolume_id, libvolume_id-devel, libvolume_id1, udev, udev-debuginfo, udev-debugsource Products: openSUSE 10.3 (i386, ppc, x86_64) openSUSE 11.0 (debug, i386, ppc, x86_64) openSUSE 11.1 (debug, i586, ppc, x86_64)
hmm. on secondary review I see you fioxed the netlink issue, but not the overflow. any reason for the overflow niot being fixed? (I have released the netlink fix as it was urgent already)
No reason. I have just been informed about the netlink issue as a matter of urgency, and prepared the patch etc whilst being on the road (at the collaboration summit to be precise). And the overflow was deemed of a rather low urgency, as you would have to prepare a _kernel_ device path consisting of just unicode characters. Anyone capable of doing so deserves the merit of crashing udev :-) And we would be crashing the udev worker programs only, so at worst udev wouldn't generate a device node for this; I can't really see how it would affect udevd itself. Hence the rather low urgency here.
adding to the advisory: 5) Pending Vulnerabilities, Solutions, and Work-Arounds: The fix for the buffer overflow in util_path_encode() (CVE-2009-1186) has been postponed to a later udev release due to the urgency of the netlink problem. It is also rated lower, since local users cannot directly trigger the problematic code path.
update released, advisory released, new bug for the second issue is bug 495586
hmpf, udev on sles10 does not auto-restart, so customers need to restart udevd themselves. the other distros do restart on update.
Patch25: udev-netlink-credentials is NOT APPLIED to the SLE10-SP2 update!
Only sles10-sp2 missed it, the others did not. I resubmitted udev to sle10sp2, did a new patchinfo and submitted it. I also marked udev as RebootNeeded: yes, since it does not autorestart on sle10.
Updated multipath-tools has been submitted to maintenance for SLES10 SP2.
Any update for this bug, Regis? It somehow got stalled.
Resubmitted new multipath-tools rpm for SLES10-SP2.
Update released for: multipath-tools Products: SLE-DEBUGINFO 10-SP2 (i386, ia64, ppc, s390x, x86_64) SLE-DESKTOP 10-SP2 (i386, x86_64) SLE-SERVER 10-SP2 (i386, ia64, ppc, s390x, x86_64)
CVE-2009-1185: CVSS v2 Base Score: 7.2 (AV:L/AC:L/Au:N/C:C/I:C/A:C)
*** Bug 1034330 has been marked as a duplicate of this bug. ***