PostUp/PreUp/PostDown/PreDown Dangerous?

[Jason A. Donenfeld]

Hi Jacob,

Thanks for writing in, and for your original blog post. It looks to me
like most people on the mailing list don't know how to use their email
clients, and so you're getting cut off from the responses. However, if
you're interested, they are at least in the archives, starting with
the parent post:
https://lists.zx2c4.com/pipermail/wireguard/2018-June/003032.html

On Fri, Jun 22, 2018 at 3:08 PM Jacob Baines <baines.jacob at gmail.com> wrote:
>   My main problem with "--script-security" is that its useless. It just causes OpenVPN to spit a line into a log file (and by that time its too late anyways). That isn't a security mechanism.

Yes, --script-security doesn't solve much at all for this use case,
especially because it can be put inside the config file itself, so
that by the time somebody runs `openvpn --config pwnd.conf`, it's too
late. I think the suggestion in this case would be to add something to
wg-quick(8) along the lines of:

$ wg-quick up --i-recognize-this-config-file-might-murder-kittens pwnd.conf

I don't actually think that helps much though. The users you want to
protect from pwnd.conf will still paste that line verbatim anyway, and
it's just another nob that risks making the whole thing a hassle (like
OpenVPN is with all of those nobs).

>   There also seems to be an expectation that users should understand these config files. I'm not sure why that is. Excuse my speaking in generalities but a majority of users aren't going to understand how OpenVPN works, let alone how the configuration file affects the program. Many users (myself included) simply receive config files from our bosses or our IT guy and trust that they aren't malicious. Call me naive or foolish but I don't review every single file passed my way for malicious content.

Yes, that's a very fair assessment of the situation with OpenVPN.
There are a million nobs, and including massive x509 certs inline with
the config makes the whole thing an unscanable mess. I've read the
entire code base of OpenVPN several times and played with nearly every
feature, but I still can't remember off the topic of my head the
semantics of all those nobs. By contrast, a typical wg-quick(8) config
file looks like:

zx2c4 at thinkpad ~ $ cat /etc/wireguard/demo.conf
[Interface]
PrivateKey = gP+/hJKAhmXKmewrgpkrOKYwvwGwHQ3i5bQqVzWpoEI=
Address = 192.168.4.207/24
DNS = 8.8.8.8, 8.8.4.4, 1.1.1.1, 1.0.0.1

[Peer]
PublicKey = JRI8Xc0zKP9kXk8qP84NdUQA04h6DLfFbwJn4g+/PFs=
Endpoint = demo.wireguard.com:12912
AllowedIPs = 0.0.0.0/0

Turns out, though, that our [Interface] section above can also contain
{Post,Pre}{Up,Down}, hence this email thread.

>    Furthermore, I've heard a few times now "config files exec things". Off the top of my head, I can't think of any other applications that execute shell commands listed in their configuration file. I have no idea where that is coming from. Its not a smart practice from a security point of view.

Just going haphazardly through the various random applications on my
laptop, I can think of quite a few actually:

vim
git
mutt
msmtp
chromium
firefox
kde
qtcreator
bash (haha)
portage
systemd
dhcpcd
texstudio
networkmanager
apache
emacs
Most things in /etc/...

I think it's pretty typical for application configuration files on
unix systems to wind up exec'ing things. Configuration is often seen
as a combination of code and data.

On the other hand, there's a set of applications that take purely data
input, and we certainly expect them to not execute anything. This
would apply to things like:

pdf docs
msoffice docs (turing complete!)
jpeg images
text files
sound files
video files
archives

One might conclude from this distinction that configuration files are
not like word files, and therefore should be permitted to execute
things. But if that's the case, is there any real difference between a
configuration file and just shipping around a bash script or elf
binary? Or you could argue that a configuration file is sometimes just
sort of a domain-specific command executor. This is also an
unsatisfying conclusion. So I'm not sure what formal distinction one
should draw in the end, except, "sometimes on unix, it's traditional
and common for configuration files to execute things." Hm.

> I'd try to migrate code into OpenVPN itself or the plugin system

It's worth noting that OpenVPN's configuration file can load
plugins... So... Here's a fun exercise: can you make a polyglot file
that's parsed both as an openvpn configuration file and as an
ELF/PE/Mach-O shared library that the loader will execute code from?
Then you could just specify "plugin /proc/self/fd/3" or the like. Or
there's always the drive-by download trick, where you get a .notadll
file put in the user's download folder for free (and since it isn't a
.dll, it's not handled specially), and then benefit from the fact that
OpenVPN's plugin directive doesn't check file extension. Or, ... okay,
I'll stop now.

Jason