netdev - Re: syzkaller wireguard key situation [was: Re: [PATCH net-next v2] net: WireGuard secure network tunnel]

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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 20 Feb 2020 17:44:53 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     netdev <netdev@...r.kernel.org>,
        syzbot <syzkaller@...glegroups.com>,
        WireGuard mailing list <wireguard@...ts.zx2c4.com>
Subject: Re: syzkaller wireguard key situation [was: Re: [PATCH net-next v2]
 net: WireGuard secure network tunnel]

On Thu, Feb 20, 2020 at 5:34 PM Jason A. Donenfeld <Jason@...c4.com> wrote:
>
> Hi Dmitry,
>
> On Thu, Feb 20, 2020 at 5:14 PM Dmitry Vyukov <dvyukov@...gle.com> wrote:
> > I got some coverage in wg_netdevice_notification:
> > https://imgur.com/a/1sJZKtp
> >
> > Or you mean the parts that are still red?
>
> Yes, it's the red parts that interest me. Intermixing those with
> various wireguard-specific netlink calls and setting devices up and
> down and putting traffic through those sockets, in weird ways, could
> dig up bugs.
>
> > I think theoretically these parts should be reachable too because
> > syzkaller can do unshare and obtain net ns fd's.
> >
> > It's quite hard to test because it just crashes all the time on known bugs.
> > So maybe the most profitable way to get more coverage throughout the
> > networking subsystem now is to fix the top layer of crashers ;)
>
> Ahhh, interesting, so the issue is that syzkaller is finding too many
> other networking stack bugs before it gets to being able to play with
> wireguard. Shucks.


If it's aimed only at, say, wireguard netlink interface, then it's not
distracted by bugs in other parts. But as you add some ipv4/6 tcp/udp
sockets, more netlink to change these net namespaces, namespaces
related syscalls, packet injection, etc, in the end it covers quite a
significant part of kernel. You know how fuzzing works, right. You
really need to fix the current layer of bugs to get to the next one.
And we accumulated 600+ open bugs. It still finds some new ones, but I
guess these are really primitive ones (as compared to its full bug
finding potential).