OpenVPN[v2.0.x]: foreign_option() formart string vulnerability.
v9@xxxxxxxxxxx: OpenVPN[v2.0.x]: foreign_option() format string vulnerability.
1. BACKGROUND
OpenVPN is a robust and highly configurable VPN (Virtual Private Network)
daemon which
can be used to securely link two or more private networks using an encrypted
tunnel over
the Internet. OpenVPN's principal strengths include wide cross-platform
portability,
excellent stability, support for dynamic IP addresses and NAT, adaptive link
compression,
single TCP/UDP port usage, a modular design that offloads most crypto tasks to
the
OpenSSL library, and relatively easy installation that in most cases doesn't
require a
special kernel module.
2. DESCRIPTION
OpenVPN(v2.0.x) contains a remotely exploitable format string bug in the
processing of
its command-line/config arguments.
the vulnerable function is located in options.c in the foreign_option()
function. this
function uses the buf_printf() function to improperly write to a buffer(typical
printf()
format string-style). the only option that appears to use the foreign_option()
function
is "dhcp-option".
this, by itself, seems relatively useless. however, since the OpenVPN server is
allowed to "push" some command options ("dhcp-option" being one of those) to
its clients
this becomes remotely exploitable to OpenVPN clients. an example/demonstration
of this
would be to insert the following line into a malicious OpenVPN server config
file:
push "dhcp-option <format string>"
or, namely to test for validity/crash of an OpenVPN client:
push "dhcp-option %n%n%n%n%n%n"
it should be noted that WIN32 versions of OpenVPN are NOT affected by this, the
following code snippets will highlight the above.
----------------------------------------------------------------------------------------
openvpn/options.c:
...
static void
foreign_option (struct options *o, char *argv[], int len, struct env_set *es)
{
if (len > 0)
{
struct gc_arena gc = gc_new();
struct buffer name = alloc_buf_gc (OPTION_PARM_SIZE, &gc);
struct buffer value = alloc_buf_gc (OPTION_PARM_SIZE, &gc);
int i;
bool first = true;
buf_printf (&name, "foreign_option_%d", o->foreign_option_index + 1);
++o->foreign_option_index;
for (i = 0; i < len; ++i)
{
if (argv[i])
{
if (!first)
buf_printf (&value, " ");
! -> buf_printf (&value, argv[i]);
first = false;
}
}
setenv_str (es, BSTR(&name), BSTR(&value));
gc_free (&gc);
}
}
...
static int
add_option (...){
...
#ifdef WIN32
...
#else
...
else if (streq (p[0], "dhcp-option") && p[1])
{
++i;
VERIFY_PERMISSION (OPT_P_IPWIN32);
if (p[2])
++i;
! -> foreign_option (options, p, 3, es);
}
...
#endif
...
----------------------------------------------------------------------------------------
it should also be noted the OpenVPN manpage states:
----------------------------------------------------------------------------------------
--push option
Push a config file option back to the client for remote execu-
tion. Note that option must be enclosed in double quotes ("").
The client must specify --pull in its config file. The set of
options which can be pushed is limited by both feasibility and
security. Some options such as those which would execute
scripts are banned, since they would effectively allow a compro-
mised server to execute arbitrary code on the client. Other op-
tions such as TLS or MTU parameters cannot be pushed because the
client needs to know them before the connection to the server
can be initiated.
This is a partial list of options which can currently be pushed:
--route, --route-gateway, --route-delay, --redirect-gateway,
--ip-win32, --dhcp-option, --inactive, --ping, --ping-exit,
--ping-restart, --setenv, --persist-key, --persist-tun, --echo
----------------------------------------------------------------------------------------
however, when testing i did NOT have to have the "pull" option in my clients
config
file to allow the "push"ed dhcp-option request as it states above.
while testing i found that user-supplied data was reachable (about ~90 pops
away for me)
for writing to, and addresses (within pop/"direct parameter access" range)
already in memory
were viable to write to to gain control of the program. however, OpenVPN
filters many
characters, which causes problems for standard exploitation using the
user-supplied method
and insertion of (non-alnum) shellcode. this does not stop exploitation using
this method,
but does make it more involved.
the 1.6 version branch does not appear to have the vulnerable code present, the
first
occurance i found of the code was in 2.0beta11(the earliest version i could
find of the
2.0 branch)
3. ANALYSIS
successful exploitation of this vulnerability will result in the ability of
malicious or
compromised OpenVPN servers to run arbitrary code on OpenVPN clients.
vade79 -> v9@xxxxxxxxxxx -> fakehalo.us