Date: Wed, 23 Apr 2014 14:36:48 -0700 From: ebiederm@...ssion.com (Eric W. Biederman) To: Andy Lutomirski <luto@...capital.net> Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: CVE-2014-0181: Linux network reconfiguration due to incorrect netlink checks Andy Lutomirski <luto@...capital.net> writes: > [I think something went wrong with the quoting in here.] > > On Wed, Apr 23, 2014 at 9:27 AM, <cve-assign@...re.org> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >>> It 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=2 >> >>> Andy 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
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ