OpenVPN

I could be mistaken, but it looks to me like if you use ./configure
--enable-iproute2 and run an OpenVPN client with --pull introduces a
security hole where the OpenVPN server can execute arbitrary code on the
client machine as the user that the OpenVPN client runs as.

In some contexts, this seems like it will be unacceptable. The purpose of
OpenVPN is to open up a secure communication channel between the two
endpoints, not to open up a security hole that lets the server take control
of the client. There are reasonable deployment scenarios where the client
doesn't fully trust the server: we want to enable them to communicate
information without others snooping/tampering with those communicated bits,
but if the server is malicious, we don't want it to be able to run code on
the client side or subvert the client OpenVPN process. If I understand
correctly, in those contexts, this would be a security breach. Is that
right?

Analysis and code excerpts:

add_option() in options.c:

#ifdef CONFIG_FEATURE_IPROUTE
else if (streq (p[0], "iproute") && p[1])
{
VERIFY_PERMISSION (OPT_P_UP);
iproute_path = p[1];
}
#endif

So OPT_P_UP permission is enough to allow setting of iproute_path.

pull_permission_mask() in init.c:

unsigned int
pull_permission_mask (const struct context *c)
{
unsigned int flags =
OPT_P_UP
| ...
return flags;
}

incoming_push_message() in push.c:

status = process_incoming_push_msg (c,
buffer,
c->options.pull,
pull_permission_mask (c),
&option_types_found);

So when an push message is received from the server by the client, we call
process_incoming_push_msg() with a permission mask that includes OPT_P_UP.
process_incoming_push_msg() in turn calls add_option() with the same
permission mask, so the 'iproute' option is allowed to be pushed from the
server to the client, and the client will honor it. Finally, it's easy to
verify that iproute_path is used as the path to a script/program that is
executed upon various occasions (e.g., to set up routing tables) by calling
openvpn_system(). So I suspect this is an arbitrary code execution
vulnerability, since the server can control that path completely.

This looks to me like a remotely exploitable vulnerability, but I have not
attempted to confirm it, so my analysis could well be mistaken or faulty.
Please double-check my reasoning carefully.

This only applies to OpenVPN clients that are compiled using ./configure
--enable-iproute2, which is not enabled by default (fortunately).
Unfortunately the OpenVPN recommends enabling this configure option if you
want to run OpenVPN in unprivileged mode: in fact, in this case
--enable-iproute2 is required. So exactly in the situation where sysadmins
want to run OpenVPN as securely as possible, we'll be vulnerable to this
issue (I think).

Possible fix: Require the OPT_P_GENERAL permission flag to use --iproute,
not just OPT_P_UP, so that --pull requests don't honor this command. I
don't know whether this will break important functionality.

Again, you'll want to check my analysis for yourself.