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

[Kyle Evans]

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.

> 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