Running OC as Root: Security Implications?

[David Woodhouse]

On Tue, 2012-06-26 at 07:34 -0500, Orin L. wrote:
>  Could running OpenConnect as root open my desktop
> system to potential security threats?

Theoretically, yes. It's vaguely possible that if there were a bug in
OpenConnect, a malicious server *might* be able to exploit it.

You're better off with OpenConnect than with Cisco's own client, which
also ran as root — we *know* that Cisco's client had stupid bugs, such
as opening fixed filenames in /tmp — thus allowing any unprivileged user
on the system to trick it into overwriting *any* file on the system, as
root, just by making a symlink to the victim file from /tmp!

And that's just the one we happened to notice; we haven't been able to
do a full security audit of the Cisco code, or ensure that it's built
with PIE or any of the other protection measures which are normal these
days for Linux distributions.

Note that you don't necessarily need NetworkManager if you want to run
OpenConnect as non-root. One option doesn't need root at all; you could
even do it on a machine that someone else owns. Just use the
'--script-tun' option and it'll pass all its packets to stdin/stdout of
a separate program, instead of to a tun device. That program can listen
as a SOCKS server on the local machine, and forward all the connections
into the VPN. There's an implementation of such a server at
http://dme.org/ocproxy (Thanks David for sending that).

Or if you want to keep it simple and you *do* actually want to route
packets "properly" from your host to the VPN, you can still run
OpenConnect as an unprivileged user. On Linux you can create the tun
device in advance and assign it to the appropriate user with 'ip
tuntap', and tell OpenConnect the name of the device you want it to use.
Then it's just case of *configuring* the network according to the
information you get from the server, which is all done by vpnc-script
anyway, not OpenConnect itself. It shouldn't be hard to contrive
something which runs instead of vpnc-script, which just passes all the
configuration information back to a small tool that *does* run as root.
Or maybe you could make a setuid wrapper for vpnc-script so that only
*it* runs with root privs. You'd want to vet its input very carefully, I
suspect.

OpenConnect has a --setuid option which makes it drop privileges after
connecting, but then it doesn't have those privs when it runs
vpnc-script a second time to disconnect — so it can't put your DNS back
to normal, and your default route. It's only really useful if you don't
*use* a default route on the VPN, or VPN DNS.

Perhaps we should patch OpenConnect so that it can fork before
connecting, and do *almost* everything as root except invoking
vpnc-script. The parent can remain root, while the child becomes an
unprivileged user and does the network part. The child can pass the
network information over a UNIX socket back to the parent, which invokes
vpnc-script. And then waits for the child to die before invoking
vpnc-script a second time to disconnect.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120626/4730dde9/attachment.bin>