netdev - 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, 19 Dec 2019 12:38:02 +0100
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     netdev <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Greg KH <gregkh@...uxfoundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
        <linux-crypto@...r.kernel.org>
Subject: Re: [PATCH net-next v2] net: WireGuard secure network tunnel

On Thu, Dec 19, 2019 at 12:19 PM Dmitry Vyukov <dvyukov@...gle.com> wrote:
> > Ahh, cool, okay. Netlink, device creation, and basic packet structure
> > is a good start. What about the crypto, though?
>
> It depends. What exactly we need there?
> syzkaller uses comparison operand interception which allows it e.g. to
> guess signatures/checksums in some cases.

I don't think you'll have too much luck with WireGuard here. Fuzzing
your way to a valid handshake message involves guessing the 4th
preimage of some elliptic curve scalar multiplication, with some
random/changing data mixed in there every time you make a new try.
There's a condensed protocol description here which should be less bad
to glance at than the academic paper:
https://www.wireguard.com/protocol/#first-message-initiator-to-responder
. The fuzzers I've written for the crypto bits of WireGuard always
involve taking a complete handshake implementation and mutating things
from there. So maybe the "outer packet" won't be too fruitful without
a bunch of work. At the very least, we can generate packets that have
the right field sizes and such, and that should test the first level
of error cases I guess.

However, there's still a decent amount of surface on the "inner
packet". For this, we can set up a pair of wireguard interfaces that
are preconfigured to talk to each other (in common_linux.h, right? Or
do you have some Go file that'd be easier to do that initialization
in?), and then syzkaller will figure out itself how to send nasty IP
packets through them with send/recv and such. There's a bit of surface
here because sending packets provokes the aforementioned handshake,
and also moves around the timer state machine. The receiver also needs
to do some minimal parsing of the received packet to check
"allowedips". So, good fodder for fuzzing.