wireguard.lists.zx2c4.com archive mirror
 help / color / mirror / Atom feed
From: Dario Bosch <mail@dariobosch.de>
To: wireguard@lists.zx2c4.com
Subject: Re: PostUp/PreUp/PostDown/PreDown Dangerous?
Date: Sat, 23 Jun 2018 09:02:58 +0200	[thread overview]
Message-ID: <0674ca33-bccc-95f3-ab9f-674943b6cc3d@dariobosch.de> (raw)
In-Reply-To: <654faeee-748b-77e6-2b26-a5216800b6d0@unstable.cc>

Hi all,

I've been following this discussion and now also want to add my 2 cents.

In my opinion wireguard's biggest strength is the simplicity of its
config. One can write a 8-line config file that works reliably, is
secure and also can take care of ip tables rules, start services etc.
Even a user who only has a rough understanding about their system can
achieve this.
Everything that makes using wireguard more complicated should be
avoided. Setting up other VPNs such as openVPN is a hassle simply
because they are *not* designed to be simple.

We are discussing about an attack scenario, where the attacker convinces
a clueless user to compile/install a kernel module, we always should
keep that in mind. Most installation instructions advise people to add a
custom repository or clone a git repository, so they're already running
foreign, untrusted code with root rights.

In my opinion the only viable option would be to computer a check-sum
over the {Pre/Post}{Up/Down} lines in the config files i wg-quick. In
case the check-sum has changed, the user could then be asked to trust
this file. I imagine it a bit like that:

    [root@machine /]$ wg-quick up myWG
    [#] *New Post-Up rule detected*
    [#] Warning: The selected config file will execute the following
    [#] commands when loaded:
    [#]      'rm -rf /'
    [#] Do you want to trust this config file? [y]/[n]
       > y
    [#] Rule added to list of trusted config, continuing
    ...

Again, I think making wireguard usage more complicated and annoying than
necessary should be avoided.

Cheers,
Dario




On 06/23/2018 04:36 AM, Antonio Quartulli wrote:
> Hi,
> 
> On 23/06/18 06:13, Jordan Glover wrote:
> [cut]
>>
>> But attacker will helpfully provide you customized 'wireguard.script'  as well
>> and even tell you how to use it by setting 'chmod 4777 wireguard.script'.
>>
> 
> An attacker will also tell you to run "rm -Rf /" :-P
> 
> 
> Jokes apart, I was talking to Jason on IRC and I suggested an idea that
> might be worth sharing.
> 
> A network device driver in the kernel is free to send events to
> userspace with any custom set of properties/values.
> 
> Most of you have already seen and played with those typically thrown
> when an interface goes up and down, with udev normally handling them by
> executing some (user-)configured action.
> 
> These events can be easily created and customized by any kernel module
> and associated to a network interface.
> Wireguard could generate preup/postup/etc.. uevents and send them to
> userspace.
> 
> It will then be udev to decide how to handle those.
> Specific scripts could be installed by the admin, or udev could come
> with its own default ones.
> 
> In any case, this would delegate the execution of scripts to a component
> that is in charge of doing exactly that.
> 
> This would remove the risk of sneaking malicious things into the
> configuration file, which is what people do not expect and is the core
> of the issue discussed here.
> 
> (Yeah, I already hear people saying "but the malicious attacker will
> tell the clueless user to install this script in udev", but I think that
> by then, the problem has moved to another plane)
> 
> My experience with this mechanism comes from batman-adv[1], where it
> used to report special routing events to the user so that he could react
> accordingly (if desired).
> 
> 
> just my 2 cents.
> 
> 
> Cheers,
> 
> [1]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/batman-adv/sysfs.c#n1209
> 
> 
> 
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
> 

      reply	other threads:[~2018-06-23  6:57 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-22  1:34 PostUp/PreUp/PostDown/PreDown Dangerous? Jason A. Donenfeld
2018-06-22  1:35 ` Jason A. Donenfeld
2018-06-22  1:41   ` Jason A. Donenfeld
2018-06-22  1:55     ` logcabin
2018-06-22  1:56     ` Antonio Quartulli
2018-06-22 10:46       ` Jordan Glover
2018-06-22 10:53         ` Antonio Quartulli
2018-06-22 13:08           ` Jacob Baines
2018-06-22 14:47             ` Andy Dorman
2018-06-22 15:14             ` Matthias Urlichs
2018-06-22 17:11             ` Jason A. Donenfeld
2018-06-22  4:01     ` Matthias Urlichs
2018-06-22  5:44     ` Reto Brunner
2018-06-22 14:07     ` Andy Dorman
2018-06-23 19:16       ` Reto Brunner
2018-06-22 19:26     ` Lonnie Abelbeck
2018-06-22 22:13       ` Jordan Glover
2018-06-23  2:36         ` Antonio Quartulli
2018-06-23  7:02           ` Dario Bosch [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=0674ca33-bccc-95f3-ab9f-674943b6cc3d@dariobosch.de \
    --to=mail@dariobosch.de \
    --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).