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

[Dmitry Vyukov <dvyukov@google.com>]

On Tue, Feb 4, 2020 at 10:39 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> Hey Dmitry,
>
> I see you got wireguard's netlink stuff hooked up to syzkaller.
> Excellent work, and thanks! It's already finding bugs.
>
> Right now it seems to know about 5 different keys you've come up with,
> and not much in the way of endpoints. I think we can improve this.
>
> For keys, there are a few cases we care about:
>
> 1) Low order keys
> 2) Negative keys
> 3) Normal keys
> 4) Keys that correspond to other keys (private ==> public)
>
> For this last point, if we just have a few with that correspondance
> quality in there, syzkaller will eventually wind up configuring two
> interfaces that can talk to each other, which is good. Here's a
> collection of keys you can use, in base64, that will cover those
> cases, if you want to add these instead of the current ones in there:
>
> 1)
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
> 4Ot6fDtBuK4WVuP68Z/EatoJjeucMrH9hmIFFl9JuAA=
>
> 2)
> 2/////////////////////////////////////////8=
> TJyVvKNQjCSx0LFVnIPvWwREXMRYHI6G2CJO3dCfEdc=
>
> 3,4)
> oFyoT2ycjjhT4v16cK4Psg+hUmAMsAhFF08IB2+NeEM=
> l1ydgcmDyCCe54ElS4mfjtklrp8JI8I8YvU8V82/aRw=
> sIBz6NROkePakiwiQ4JEu4hcaeJpyOnYNbEUKTpN3G4=
> 0XMomfYRzYmUA01/QT3JV2MOVJPChaykAGXLYxG+aWs=
> oMuHmkf1vGRMDmk/ptAxx0oVU7bpAbn/L1GMeAQvtUI=
> 9E2jZ6iO5lZPAgIRRWcnCC9c6+6LG/Xrczc0G0WbOSI=
>
> That's 10 keys total, which should be a decent collection to replace
> your current set of hard coded keys in there. You can unbase64 these
> into C format with commands like:
>
> $ echo '2/////////////////////////////////////////8=' | base64 -d | xxd -i
>   0xdb, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
>   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
>   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff
>
> The second thing is getting two wireguard interfaces to talk to each
> other. This probably should happen over localhost. That means the
> listen port of one should be the endpoint of the other. So maybe you
> can get away fuzzing these with:
>
> Listen ports:
> 51820
> 51821
> 51822
> [randomly selected]
>
> and
>
> Endpoints:
> 127.0.0.1:51820
> 127.0.0.1:51821
> 127.0.0.1:51822
> [::1]:51820
> [::1]:51821
> [::1]:51822
> [randomly selected]
>
> Finally the "allowed ips" for a peer, the routing table entry that
> points to wireguard, and the packet that's being sent, should all
> somehow correspond. But probably an allowed ips of 0.0.0.0/0 will
> eventually be fuzzed to, which covers everything for the first part,
> so let's see if the rest falls into place on its own.
>
> What do you think of all that?
>
> Jason

Hi Jason,

[getting through backlog after a tip...]

I think you addressed all of this by now, right? And we got decent
coverage of wireguard. Anything else low hanging left?

https://github.com/google/syzkaller/commit/2c71f1a9122cc3cb0abacbbec6359c40db02be35
https://github.com/google/syzkaller/commit/4d1ab643be2091f794ec55d83ec8acf7b0a60be3
https://github.com/google/syzkaller/commit/c5ed587f4af5e639f7373d8ebf10ac049cb9c71b

Thanks!
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard