oss-sec mailing list archives
Re: CVE-2014-0181: Linux network reconfiguration due to incorrect netlink checks
From: ebiederm () xmission com (Eric W. Biederman)
Date: Wed, 23 Apr 2014 14:36:48 -0700
Andy Lutomirski <luto () amacapital net> writes:
[I think something went wrong with the quoting in here.] On Wed, Apr 23, 2014 at 9:27 AM, <cve-assign () mitre org> wrote:-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1It is possible to reconfigure the network on Linux by calling write(2) on an appropriately connected netlink socket. By passing such a socket as stdout or stderr to a setuid program, anyone can reconfigure the network.http://marc.info/?l=linux-netdev&m=139820127225921&w=2Andy Lutomirski when looking at the networking stack noticed that it is possible to trick privileged processes into calling write on a netlink socket and send netlink messages they did not intend. In particular from time to time there are suid applications that will write to stdout or stderr without checking exactly what kind of file descriptors those are and can be tricked into acting as a limited form of suid cat. In other conversations the magic string CVE-2014-0818 has been used to talk about this issue.First, CVE-2014-0818 is not the correct CVE ID. CVE-2014-0818 is associated only with a vulnerability in AutoCAD. A CVE ID of CVE-2014-0181 was in the Subject line.
Apparently I was disgraphic when I copied that line. My apologies.
Also, there are two messages that discuss apparently distinct types of security issues, suggesting that two or more CVE IDs may be needed: http://marc.info/?l=linux-netdev&m=139820138225967&w=2 "The caller needs capabilities on the namespace being queried, not on their own namespace. This is a security bug, although it likely has only a minor impact." (The patch is in the packet_diag_dump function in net/packet/diag.c, but the issue originally was in the sock_diag_put_filterinfo function in net/core/sock_diag.c.)This may need a new CVE. I'm not really clear on what the impact of this is, if any. It's an information disclosure issue, but I'm not entirely sure that valuable information is being disclosed.
When rebasing ontop of net this patch goes away. I only addressed this issue at all because that was one of the capable calls that needed to be fixed for the second issue, and the permission check really did need to be moved to be correct from the dump context. As the skb available in that function was the skb to write data into, not the skb of the netlink request we were authenticating.
http://marc.info/?l=linux-netdev&m=139820147526004&w=2 "verify that the opener of the socket had the desired permissions as well"This is the proposed method of fixing CVE-2014-0181
Yes. The rest of the patches are just cleanups and infrastructure to allow that change to happen. Eric
Current thread:
- CVE-2014-0181: Linux network reconfiguration due to incorrect netlink checks Andy Lutomirski (Apr 22)
- Re: CVE-2014-0181: Linux network reconfiguration due to incorrect netlink checks Andy Lutomirski (Apr 22)
- Re: CVE-2014-0181: Linux network reconfiguration due to incorrect netlink checks cve-assign (Apr 23)
- Re: CVE-2014-0181: Linux network reconfiguration due to incorrect netlink checks Andy Lutomirski (Apr 23)
- Re: CVE-2014-0181: Linux network reconfiguration due to incorrect netlink checks Eric W. Biederman (Apr 23)
- Re: CVE-2014-0181: Linux network reconfiguration due to incorrect netlink checks cve-assign (Apr 23)
- Re: CVE-2014-0181: Linux network reconfiguration due to incorrect netlink checks Andy Lutomirski (Apr 28)
- Re: CVE-2014-0181: Linux network reconfiguration due to incorrect netlink checks Andy Lutomirski (Apr 22)