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]
Message-ID: <CAHmME9ofmwig2=G+8vc1fbOCawuRzv+CcAE=85spadtbneqGag@mail.gmail.com>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ