| Summary: | <sys-apps/busybox-1.23.1: unprivileged arbitrary module load via basename abuse (CVE-2014-9645) | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Agostino Sarubbo <ago> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | embedded, williamh |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://bugzilla.redhat.com/show_bug.cgi?id=1185707 | ||
| Whiteboard: | A2 [glsa cleanup] | ||
| Package list: | Runtime testing required: | --- | |
(In reply to Agostino Sarubbo from comment #0) > > @maintainer(s): after the bump, in case we need to stabilize the package, > please let us know if it is ready for the stabilization or not. We have 1.23.0 stabilized which was not mentioned in that bug report, only 1.22 is. But upstream released 1.23.1 on jan 27, which they are expliticly saying fixes the bug, so I'll add 1.23.1 to the tree now and we'll see about stabilizing it soon. (In reply to Anthony Basile from comment #1) > (In reply to Agostino Sarubbo from comment #0) > > > > @maintainer(s): after the bump, in case we need to stabilize the package, > > please let us know if it is ready for the stabilization or not. > > We have 1.23.0 stabilized which was not mentioned in that bug report, only > 1.22 is. But upstream released 1.23.1 on jan 27, which they are expliticly > saying fixes the bug, so I'll add 1.23.1 to the tree now and we'll see about > stabilizing it soon. It looks like they lumped all their commits after 1.23.0 into one commit when backporting to the 1_23_stable branch. It does include a lot of modprobe path stuff so it looks like we need 1.23.1. http://git.busybox.net/busybox/commit/?h=1_23_stable&id=1ecfe811fe2f70380170ef7d820e8150054e88ca We should rapid stabilze 1.23.1. Arch teams, the targets are KEYWORDS="alpha amd64 arm hppa ia64 m68k ppc ppc64 sparc x86" *** Bug 530688 has been marked as a duplicate of this bug. *** Arch teams, please test and mark stable: =sys-apps/busybox-1.23.1 Targeted stable KEYWORDS : alpha amd64 arm hppa ia64 ppc ppc64 sparc x86 Stable for HPPA. Arch teams, the target is now 1.23.1-r1. Please continue stabilization. amd64 stable x86 stable arm stable ppc and ppc64 are stable. I also marked amd64 and x86 stable for the -r1. sparc stable ia64 stable alpha stable. Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one. GLSA request filed This issue was resolved and addressed in GLSA 201503-13 at https://security.gentoo.org/glsa/201503-13 by GLSA coordinator Mikle Kolyada (Zlogene). |
From ${URL} : Matthias Krause reports: modprobe uses the "basename" of the module argument as the module to load, as can be seen here: bbox:~# lsmod | grep vfat bbox:~# modprobe foo/bar/baz/vfat bbox:~# lsmod | grep vfat vfat 17135 0 fat 61984 1 vfat bbox:~# find /lib/modules/`uname -r` -name vfat.ko /lib/modules/3.18.0-rc5+/vfat.ko It should instead fail to load the module -- actually fail to *find* the module. This can even be abused to load arbitrary modules by nullifying enforced module prefixes some of the Linux kernel's subsystems try to apply to prevent just that: bbox:~# lsmod | grep usb bbox:~# ifconfig /usbserial up ifconfig: SIOCGIFFLAGS: No such device bbox:~# lsmod | grep usb usbserial 32201 0 The actual modprobe invocation, done by the kernel was: /sbin/modprobe -q -- netdev-/usbserial Due to the bug, the "netdev-" prefix including the "/" are ignored and the usbserial.ko module gets loaded. The same works for filesystems, e.g.: bbox:~# lsmod | grep snd_pcm bbox:~# mount -t /snd_pcm none / mount: mounting none on / failed: No such device bbox:~# lsmod | grep snd_pcm snd_pcm 88826 0 snd_timer 26606 1 snd_pcm snd 61141 2 snd_pcm,snd_timer This time the kernel called out to: /sbin/modprobe -q -- fs-/snd_pcm Note the "fs-" prefix. External reference: https://bugs.busybox.net/show_bug.cgi?id=7652 (cert maybe expired) @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.