Bug 680360 - (CVE-2011-1019) CVE-2011-1019 kernel: CAP_SYS_MODULE bypass via CAP_NET_ADMIN
CVE-2011-1019 kernel: CAP_SYS_MODULE bypass via CAP_NET_ADMIN
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
public=20110224,reported=20110225,sou...
: Security
Depends On: 681772 681773 681774
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-25 04:05 EST by Eugene Teo (Security Response)
Modified: 2015-08-19 05:07 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-07-29 10:00:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Eugene Teo (Security Response) 2011-02-25 04:05:40 EST
Since a8f80e8ff94ecba629542d9b4b5f5a8ee3eb565c any process with
CAP_NET_ADMIN may load any module from /lib/modules/.  This doesn't mean
that CAP_NET_ADMIN is a superset of CAP_SYS_MODULE as modules are
limited to /lib/modules/**.  However, CAP_NET_ADMIN capability shouldn't
allow anybody load any module not related to networking.

This patch restricts an ability of autoloading modules to netdev modules
with explicit aliases.  This fixes CVE-2011-1019.

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".

Currently there are only three users of the feature in the upstream
kernel: ipip, ip_gre and sit.

    root@albatros:~# capsh --drop=$(seq -s, 0 11),$(seq -s, 13 34) --
    root@albatros:~# grep Cap /proc/$$/status
    CapInh:	0000000000000000
    CapPrm:	fffffff800001000
    CapEff:	fffffff800001000
    CapBnd:	fffffff800001000
    root@albatros:~# modprobe xfs
    FATAL: Error inserting xfs
    (/lib/modules/2.6.38-rc6-00001-g2bf4ca3/kernel/fs/xfs/xfs.ko): Operation not permitted
    root@albatros:~# lsmod | grep xfs
    root@albatros:~# ifconfig xfs
    xfs: error fetching interface information: Device not found
    root@albatros:~# lsmod | grep xfs
    root@albatros:~# lsmod | grep sit
    root@albatros:~# ifconfig sit
    sit: error fetching interface information: Device not found
    root@albatros:~# lsmod | grep sit
    root@albatros:~# ifconfig sit0
    sit0      Link encap:IPv6-in-IPv4
	      NOARP  MTU:1480  Metric:1

    root@albatros:~# lsmod | grep sit
    sit                    10457  0
    tunnel4                 2957  1 sit

For CAP_SYS_MODULE module loading is still relaxed:

    root@albatros:~# grep Cap /proc/$$/status
    CapInh:	0000000000000000
    CapPrm:	ffffffffffffffff
    CapEff:	ffffffffffffffff
    CapBnd:	ffffffffffffffff
    root@albatros:~# ifconfig xfs
    xfs: error fetching interface information: Device not found
    root@albatros:~# lsmod | grep xfs
    xfs                   745319  0

References:
https://lkml.org/lkml/2011/2/24/203
http://www.spinics.net/lists/netdev/msg156587.html

Acknowledgements:

Red Hat would like to thank Vasiliy Kulikov of Openwall for reporting this issue.
Comment 3 Eugene Teo (Security Response) 2011-03-11 19:53:06 EST
Upstream commit:
http://git.kernel.org/linus/8909c9ad8ff03611c9c96c9a92656213e4bb495b
Comment 5 Phillip Lougher 2011-03-16 15:07:34 EDT
(In reply to comment #4)
> Needs this fix too:
> http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commitdiff_plain;h=6dfbd87a20a737641ef228230c77f4262434fa24

Not strictly true, because net/ipv6/ip6_tunnel.c lacked an MODULE_ALIAS to begin with, so you couldn't autoload it as "ip6tnl0" before anyway.

Before commit 8909c9ad8ff03611c9c96c9a92656213e4bb495b

% ifconfig ip6tnl0
ip6tnl0: error fetching interface information: Device not found

After commit 8909c9ad8ff03611c9c96c9a92656213e4bb495b

% ifconfig ip6tnl0
ip6tnl0: error fetching interface information: Device not found


This commit is basically fixing the lack of a MOD_ALIAS.  Similar fixes went into mainline last year for ip_gre.c and ipip.c

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4da6a738ffdb99b88efbe5b4c4fe521ca453640d

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8afe7c8acd33bc52c56546e73e46e9d546269e2c
Comment 6 Phillip Lougher 2011-03-16 15:13:09 EDT
In other words it is an independent mainline fix, unrelated to the security hole that CVE--2011-1019 is fixing.
Comment 7 errata-xmlrpc 2011-05-10 13:20:33 EDT
This issue has been addressed in following products:

  MRG for RHEL-5

Via RHSA-2011:0500 https://rhn.redhat.com/errata/RHSA-2011-0500.html
Comment 8 errata-xmlrpc 2011-05-10 14:11:39 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 6

Via RHSA-2011:0498 https://rhn.redhat.com/errata/RHSA-2011-0498.html
Comment 9 Eugene Teo (Security Response) 2011-07-01 04:16:05 EDT
Statement:

This issue did not affect the Linux kernel as shipped with Red Hat Enterprise Linux 4 and 5 as they did not backport the upstream commit a8f80e8f that introduced this flaw. This has been addressed in Red Hat Enterprise Linux 6 and Red Hat Enterprise MRG via https://rhn.redhat.com/errata/RHSA-2011-0498.html and https://rhn.redhat.com/errata/RHSA-2011-0500.html.

Note You need to log in before you can comment on or make changes to this bug.