Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Kyle Evans <kevans@freebsd.org>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: [ANNOUNCE] WireGuard for FreeBSD in development for 13.y – and a note of how we got here
Date: Fri, 19 Mar 2021 08:03:01 -0500	[thread overview]
Message-ID: <CACNAnaFsDK7moCr1j1GYLcEdR_UYE=My7vgKB6VLnFaNzKAzOw@mail.gmail.com> (raw)
In-Reply-To: <YE9zWanlutKYTlKL@zx2c4.com>

On Mon, Mar 15, 2021 at 9:47 AM Jason A. Donenfeld <Jason@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

  parent reply	other threads:[~2021-03-19 13:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-15 14:46 Jason A. Donenfeld
2021-03-15 19:49 ` Reto
2021-03-16  1:18 ` Jason A. Donenfeld
2021-03-19 13:03 ` Kyle Evans [this message]
2021-03-19 13:38   ` Kyle Evans

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CACNAnaFsDK7moCr1j1GYLcEdR_UYE=My7vgKB6VLnFaNzKAzOw@mail.gmail.com' \
    --to=kevans@freebsd.org \
    --cc=Jason@zx2c4.com \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).