Re: CVE-2014-0181: Linux network reconfiguration due to incorrect netlink checks

[Andy Lutomirski <luto () amacapital net>]

[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: 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.
>
> 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.

> 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

--Andy