On Fri, Mar 19, 2021 at 8:03 AM Kyle Evans <[email protected]> wrote: > > On Mon, Mar 15, 2021 at 9:47 AM Jason A. Donenfeld <[email protected]> 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
