netdev - Re: Netlink mmap tx security?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALCETrVuREGVKwrni61DEg=Tgjc7x41WYtrEiDMqMvwVFXfybw@mail.gmail.com>
Date:	Mon, 12 May 2014 14:08:20 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	"David S. Miller" <davem@...emloft.net>,
	Network Development <netdev@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Patrick McHardy <kaber@...sh.net>
Subject: Re: Netlink mmap tx security?

[moving to netdev -- this is much lower impact than I thought, since
you can't set up a netlink mmap ring without global CAP_NET_ADMIN]

On Wed, May 7, 2014 at 5:46 PM, Andy Lutomirski <luto@...capital.net> wrote:
> Disclaimer: I haven't tried to write a proof-of-concept, so I could be
> wrong here.
>
>     /* Netlink messages are validated by the receiver before processing.
>      * In order to avoid userspace changing the contents of the message
>      * after validation, the socket and the ring may only be used by a
>      * single process, otherwise we fall back to copying.
>      */
>     if (atomic_long_read(&sk->sk_socket->file->f_count) > 2 ||
>         atomic_read(&nlk->mapped) > 1)
>         excl = false;
>
> How is this possibly safe?  I think it's broken for at least three reasons:
>
> 1. Shouldn't that be atomic_long(read(&f_count) > 1))?
>
> 2. threads
>
> 3. process_vm_writev
>
> I wouldn't be surprised if RDMA and AIO also break this assumption.
>
> Does anything rely on mmapped netlink tx being fast?  If not, can this
> code just be deleted?
>
> For that matter, does anything rely on mmapped netlink tx at all?
>
> (On a non-KASLR, non-SMEP system, this probably gives reliable kernel
> code execution.)
>
> For that matter, netlink_mmap_sendmsg also appears to vulnerable to a
> TOCTOU attack via hdr.
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html