According to Vasiliy Kulikov, since 2.6.32 - commit a8f80e8ff94ecba629542d9b4b5f5a8ee3eb565c to be precise - it has been possible to load any kernel module via CAP_NET_ADMIN without necessarily requiring the CAP_SYS_MODULE capability [1]. A patch was included in both 2.6.32.33 and 2.6.37.4 [2]. Among other things, the patch touches "net/ipv4/ip_gre.c", "ipv4/ipip.c" and "net/ipv6/sit.c". However, according to Chuck Ebbert of Red Hat, the IPv6 tunnel driver code at "net/ipv6/ip6_tunnel.c" also requires patching [3] [4]. Unfortunately, that was not accounted for in the stable queue patches. [1] https://lkml.org/lkml/2011/2/24/203 [2] http://git.kernel.org/linus/8909c9ad8ff03611c9c96c9a92656213e4bb495b [3] https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-1019 [4] http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commitdiff_plain;h=6dfbd87a20a737641ef228230c77f4262434fa24
Upon closer inspection, I've realised that the patch referred to by Chuck Ebbert is supplemental to the patch containing the security fix but that it apparently has no security ramifications in and as of itself. What it does is add the following to net/ipv6/ip6_tunnel.c: MODULE_ALIAS_NETDEV("ip6tnl0"); Functionally, that's equivalent to: MODULE_ALIAS("netdev-ip6tnl0"); Thus, it ensures that the underlying module can be loaded upon demand in the revised dev_load() function, provided that the CAP_NET_ADMIN capability is in effect: if (no_module && capable(CAP_NET_ADMIN)) no_module = request_module("netdev-%s", name); Unless I'm very much mistaken, because MODULE_ALIAS was not called upon prior in the ip6_tunnel code, it doesn't seem to be any more serious than that. Nevertheless, it's a worthy fix that ought to be included.
Sorry to post again so soon but there's something bothersome about the patch. While it does indeed address the vulnerability by ensuring that only those with CAP_NET_ADMIN rights can cause a module for a 'net device' to be automatically requested via dev_load(), it still allows for this sort of silliness ... # lsmod | grep fuse # ifconfig fuse fuse: error fetching interface information: Device not found # lsmod | grep fuse fuse 51297 0 An excerpt from dmesg thereafter:- [ 208.703010] Loading kernel module for a network device with CAP_SYS_MODULE (deprecated). Use CAP_NET_ADMIN and alias netdev-fuse instead Ugh! OK, there's no risk in the sense that this wouldn't be possible without the CAP_SYS_MODULE capability. Yet, it seems so wrong. The reason for the fallback code is explained in the patch comment itself:- <quote>Arnd Bergmann suggested to leave untouched the old pre-v2.6.32 behavior of loading netdev modules by name (without any prefix) for processes with CAP_SYS_MODULE to maintain the compatibility with network scripts that use autoloading netdev modules by aliases like "eth0", "wlan0".</quote> Well, that's a compelling reason, albeit a highly unpalatable one. But is this actually of any concern to Gentoo? It seems to me that this behaviour is retained so as to placate old and/or badly engineered distros - in particular, those not using udev. Allowing code to be injected into the kernel so obviously out of context is something I find a little disturbing. If there is no use case for the fallback code in Gentoo, I'm wondering whether the patch to net/core/dev.c itself should simply be as follows: if (!dev && capable(CAP_NET_ADMIN)) - request_module("%s", name); + request_module("netdev-%s", name);
Also, see https://lkml.org/lkml/2011/2/25/181 ... "It is not the kernel patching which we should worry about, kernel part is trivial. What is not trivial is to patch all the systems out there who autoloads network drivers based on /etc/modprobe.d/network-aliases.conf (some local file), ie, numerous working setups which already uses this mechanism since stone age. And patching these is not trivial at all, unfortunately." Gentoo is not stuck in the stone age, however.
(In reply to comment #3) > Also, see https://lkml.org/lkml/2011/2/25/181 ... > > "It is not the kernel patching which we should worry about, kernel > part is trivial. > > What is not trivial is to patch all the systems out there who > autoloads network drivers based on /etc/modprobe.d/network-aliases.conf > (some local file), ie, numerous working setups which already > uses this mechanism since stone age. And patching these is > not trivial at all, unfortunately." > > Gentoo is not stuck in the stone age, however. Yeah this is what I was worried about, catching all the auto-loading net drivers. Anyhow, as we discussed in IRC, hardened can work around this by enabling CONFIG_GRKERNSEC_MODHARDEN which "helps defend against attacks by unprivileged users who abuse the auto-loading behavior to cause a vulnerable module to load that is then exploited."
CVE-2011-1019 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-1019): The dev_load function in net/core/dev.c in the Linux kernel before 2.6.38 allows local users to bypass an intended CAP_SYS_MODULE capability requirement and load arbitrary modules by leveraging the CAP_NET_ADMIN capability.
There are no longer any 2.x kernels available in the repository with the exception of sys-kernel/xbox-sources which is unsupported by security.
