Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: wireguard@lists.zx2c4.com
Subject: Re: Blind Operator Mode - A Defensive Rootkit
Date: Wed, 15 Nov 2017 18:21:32 +0100	[thread overview]
Message-ID: <20171115172132.GB8360@kroah.com> (raw)
In-Reply-To: <20171115151852.GA23957@zx2c4.com>

On Wed, Nov 15, 2017 at 04:18:54PM +0100, Jason A. Donenfeld wrote:
> Hey folks,
> 
> One of the strengths of WireGuard is its visibility. wg(8) is a tiny tool
> that's easy to use, and you can configure and reconfigure everything at
> runtime, examining the current configuration, and doing other various things.
> It works well and for the most part people seem to like it.
> 
> It turns out that this strength might actually be a weakness for some. A small
> commercial VPN provider approached me recently about the fact they could see
> the allowed IPs mapping easily with WireGuard, whereas with OpenVPN it was
> hidden deep inside a process they didn't know how to debug. "Great," I
> thought. Not so fast. They were concerned that when compelled to retrieve this
> kind of information, they would no longer be able to claim, "we don't know
> how," since WireGuard makes it so easy. So, they hired me for a day to develop
> and open source a small solution for their unique use case and odd scenario.
> 
> Before reading further, do you have the same bizarre requirement? Probably
> not. In that likely case, please keep reading only under the scope of,
> "something somebody else thought they needed, but I don't need myself." In
> other words, don't use this code.
> 
> Not wanting to hack up WireGuard or add configuration nobs -- or really
> compromise any of what the project is about in response to these kinds of
> requests -- I thought I'd write a small "defensive rootkit," which most
> certainly kills both your kitten and your neighbor's parrot.
> 
> It started out by just hooking the Netlink API to zero out the endpoints and
> allowedips for each peer. Then I disabled tcpdump. Then I disabled /dev/mem,
> /dev/kmem, /dev/port, /proc/kcore, and module loading. Things were looking
> fairly clean, until I needed to add compatibility support for old kernels, and
> then I reverted to some cthulhu-style x86 opcode parsing and writing to proc
> from kernelspace and other atrocities. It seems to work relatively well on
> the kernels I've tested, but of course there are no guarantees with this kind
> of stuff. In any case, there aren't very many public rootkit examples like
> this, so at the very least it might be an aid to a college freshman doing an
> assignment for his "Intro to Computer Security" course.
> 
> Keep in mind that there are several ways to subvert each and every defense
> that this thing introduces. Several ways! All of the defenses! Subverted! For
> that reason, you shouldn't use this if you're relying on the impossibility of
> subversion. It's only meant as a confinement based on your own lack of
> knowledge on how to subvert it. As you learn more, the software becomes less
> effective.
> 
> If it's of any interest, it's online here:
> https://git.zx2c4.com/blind-operator-mode/about/
> https://git.zx2c4.com/blind-operator-mode/tree/blind-operator-mode.c
> $ git clone https://git.zx2c4.com/blind-operator-mode/
> 
> Enjoy! Please don't run this monster at home!

Ouch, my eyes!!!

That's a great kernel module, thanks for publishing it, lots of fun
things in there :)

greg k-h

      reply	other threads:[~2017-11-15 17:17 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-15 15:18 Jason A. Donenfeld
2017-11-15 17:21 ` Greg KH [this message]

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=20171115172132.GB8360@kroah.com \
    --to=gregkh@linuxfoundation.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).