All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.