Re: [ANNOUNCE] WireGuard for FreeBSD in development for 13.y – and a note of how we got here

[Kyle Evans]

On Fri, Mar 19, 2021 at 8:03 AM Kyle Evans <kevans at freebsd.org> wrote:
>
> On Mon, Mar 15, 2021 at 9:47 AM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> >
> > Hi everybody,
> >
> > [... snip ...]
> >
> > The first step was assessing the current state of the code the previous
> > developer had dumped into the tree. It was not pretty. I imagined
> > strange Internet voices jeering, “this is what gives C a bad name!”
>
> This was a highly unnecessary jab.
>
> > There were random sleeps added to “fix” race conditions
>
> This is true.
>
> > validation functions that just returned true
>
> I looked back at the history here just now, and I count one,
> wg_allowedip_valid, that pretty much got ripped out anyways.
>
> > catastrophic cryptographic vulnerabilities
> > whole parts of the protocol unimplemented
>
> I'm not qualified to speak about these two, which are perhaps the
> worst from the public's perspective.
>
> > kernel panics
>
> These are true.
>
> > security bypasses
> > overflows
>
> I only recall one of each.
>
> > random printf statements deep in crypto code
>
> This is true.
>
> > the most spectacular buffer overflows
>
> English is a crappy language, but this sounds like you're advertising
> more than one.  There was one, and for the record to anyone watching to
> dispel "the word on the street" that it's potentially an RCE: based on what's
> happening I cannot imagine how you could usefully turn it into an RCE.
> Local privileged execution, 100%, but looking at it further, you've got to be
> pretty skilled to make it before killing the kernel elsewhere.
>

Ah, I have to clarify this one; I suspect if you're acting as a wg
gateway, it's possible. It
still doesn't look like an easy one to exploit.

> > and the whole litany of awful things that go wrong when people aren’t
> > careful when they write C.
>
> This is an exceedingly broad statement, and it would have been good to provide
> some pointers to these.
>
> > [...]
>
> You know that I don't appreciate how you handled this initial communication,
> as I've told you a number of times. Now that I look at the history again, I'm
> even more disappointed in how you handled this because there are some
> pretty broad statements in here and language that could go either way.
>
> I've additionally recommended, as a developer and not in any kind of official
> capacity, that we can't include if_wg in any future version of base.  We cannot
> have our users being put at the risk of this kind of publicity if we
> can't get security
> advisories issued in time. Ports is a fine place, where security issues can be
> addressed expeditiously and more in line with how the WireGuard project chooses
> to handle them.
>
> Thanks,
>
> Kyle Evans