linux-kernel - Re: [PATCH net-next v2] net: WireGuard secure network tunnel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 18 Dec 2019 11:57:39 +0100
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     netdev <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Greg KH <gregkh@...uxfoundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
        <linux-crypto@...r.kernel.org>
Subject: Re: [PATCH net-next v2] net: WireGuard secure network tunnel

Hi Dmitry,

On Wed, Dec 18, 2019 at 11:13 AM Dmitry Vyukov <dvyukov@...gle.com> wrote:
> Does it really do "verbose debug log"? I only see it is used for
> self-tests and debug checks:

Yes, it does, via net_dbg and co. People with the Linux "dynamic
debugging" feature turned also get the log by twiddling with some file
at runtime.

> In different contexts one may enable different sets of these.
> In particular in fuzzing context one absolutely wants additional debug
> checks, but not self tests and definitely no verbose logging. CI and
> various manual scenarios will require different sets as well.
> If this does verbose logging, we won't get debug checks as well during
> fuzzing, which is unfortunate.
> Can make sense splitting CONFIG_WIREGUARD_DEBUG into 2 or 3 separate
> configs (that's what I see frequently). Unfortunately there is no
> standard conventions for anything of this, so CIs will never find your
> boot tests and fuzzing won't find the additional checks...

I agree that it might make sense to split this up at some point, but
for now I think it might be a bit overkill. Both the self-tests and
debug tests are *very* light at the moment. Down the road if these
become heavier, I think it'd probably be a good idea, but for the time
being it'd mostly be more complexity for nothing.

Another more interesting point, though, you wrote
> and definitely no verbose logging.

Actually with WireGuard, I think that's not the case. The WireGuard
logging has been written with DoS in mind. You /should/ be able to
safely run it on a production system exposed to the wild Internet, and
while there will be some additional things in your dmesg, an attacker
isn't supposed to be able to totally flood it without ratelimiting or
inject malicious strings into it (such as ANSI escape sequence). In
other words, I consider the logging to be fair game attack surface. If
your fuzzer manages to craft some nasty sequence of packets that
tricks some rate limiting logic and lets you litter all over dmesg
totally unbounded, I'd consider that a real security bug worth
stressing out about. So from the perspective of letting your fuzzers
loose on WireGuard, I'd actually like to see this option kept on.

Jason