Warning: Openconnect my overwrite your data

[Markus Robert Kessler]

For years I am setting up sudo-based cisco vpnc vpn access, so that
"normal" users can open / close vpns without root password.

Now I did the same with openconnect.
This one also provides the option "--pid-file", which is handy, because
vpnc provides a small program called "vpnc-disconnect", which looks for
the pid hardcoded in /run/vpnc.pid. So, I set up openconnect to use the
same pid-file, and hence oepnconnect can be also terminated using "vpnc-
disconnect".

Well, this option looked suspicious to me from the beginning, and so I had
a look into the sources. There I saw something like "prefix" and other
fancy things around the pid-file, and so I thought this was to "sanitize"
user input.

But it was not.

I tried "openconnect --pid-file /dev/sda ..."

and, guess? -- Yes, the box did not boot anymore.

What makes me nervous is that every non-privileged user can do the same.
Vpnc seems to have the same security hole.

I am just thinking about recompile and rebuild the packages, where this
option is excluded and the pid file is hardcoded to, let's say /run/
vpnc.pid.

Any idea?

Markus

[red floyd]

Post by Markus Robert Kessler
For years I am setting up sudo-based cisco vpnc vpn access, so that
"normal" users can open / close vpns without root password.
Now I did the same with openconnect.
This one also provides the option "--pid-file", which is handy, because
vpnc provides a small program called "vpnc-disconnect", which looks for
the pid hardcoded in /run/vpnc.pid. So, I set up openconnect to use the
same pid-file, and hence oepnconnect can be also terminated using "vpnc-
disconnect".
Well, this option looked suspicious to me from the beginning, and so I had
a look into the sources. There I saw something like "prefix" and other
fancy things around the pid-file, and so I thought this was to "sanitize"
user input.
But it was not.
I tried "openconnect --pid-file /dev/sda ..."
and, guess? -- Yes, the box did not boot anymore.
What makes me nervous is that every non-privileged user can do the same.
Vpnc seems to have the same security hole.
I am just thinking about recompile and rebuild the packages, where this
option is excluded and the pid file is hardcoded to, let's say /run/
vpnc.pid.

What the heck did you think would happen when you told it to write over
your hard drive boot sector?

[David W. Hodgins]

Post by Markus Robert Kessler
For years I am setting up sudo-based cisco vpnc vpn access, so that
"normal" users can open / close vpns without root password.
Now I did the same with openconnect.
This one also provides the option "--pid-file", which is handy, because
vpnc provides a small program called "vpnc-disconnect", which looks for
the pid hardcoded in /run/vpnc.pid. So, I set up openconnect to use the
same pid-file, and hence oepnconnect can be also terminated using "vpnc-
disconnect".
Well, this option looked suspicious to me from the beginning, and so I had
a look into the sources. There I saw something like "prefix" and other
fancy things around the pid-file, and so I thought this was to "sanitize"
user input.
But it was not.
I tried "openconnect --pid-file /dev/sda ..."
and, guess? -- Yes, the box did not boot anymore.
What makes me nervous is that every non-privileged user can do the same.
Vpnc seems to have the same security hole.
I am just thinking about recompile and rebuild the packages, where this
option is excluded and the pid file is hardcoded to, let's say /run/
vpnc.pid.
Any idea?

The openconnect binary is in /usr/sbin instead of /usr/bin because it's intended
to be restricted to people who can be trusted.

If I were trying to set it up so that untrusted regular users could still start
and stop it, look at something like mgaonline for how it does it's stuff.
/usr/bin/mgaupdate uses pkexec to run /usr/libexec/mgaupdate with root
privileges.

Assuming there are a limited number of vpn accounts that are to be used, set up
openconnect to use scripts in /usr/local/sbin that does what's needed, and create
scripts in /usr/local/bin that uses pkexec to run the sbin scripts.

Don't allow any input from the user to be passed directly to the openconnect
command. If any user input is passed, it would require very good filtering
to prevent them passing something like "configfilename='../../../dev/sda'"
or "configfilename='thefilename;rm -rf /'" instead of just a filename.

Regards, Dave Hodgins

[Markus Robert Kessler]

On Wed, 27 Sep 2023 15:51:26 -0400, Markus Robert Kessler

Post by Markus Robert Kessler
For years I am setting up sudo-based cisco vpnc vpn access, so that
"normal" users can open / close vpns without root password.
Now I did the same with openconnect.
This one also provides the option "--pid-file", which is handy, because
vpnc provides a small program called "vpnc-disconnect", which looks for
the pid hardcoded in /run/vpnc.pid. So, I set up openconnect to use the
same pid-file, and hence oepnconnect can be also terminated using
"vpnc- disconnect".
Well, this option looked suspicious to me from the beginning, and so I
had a look into the sources. There I saw something like "prefix" and
other fancy things around the pid-file, and so I thought this was to
"sanitize" user input.
But it was not.
I tried "openconnect --pid-file /dev/sda ..."
and, guess? -- Yes, the box did not boot anymore.
What makes me nervous is that every non-privileged user can do the
same. Vpnc seems to have the same security hole.
I am just thinking about recompile and rebuild the packages, where this
option is excluded and the pid file is hardcoded to, let's say /run/
vpnc.pid.
Any idea?

The openconnect binary is in /usr/sbin instead of /usr/bin because it's
intended to be restricted to people who can be trusted.
If I were trying to set it up so that untrusted regular users could
still start and stop it, look at something like mgaonline for how it
does it's stuff.
/usr/bin/mgaupdate uses pkexec to run /usr/libexec/mgaupdate with root
privileges.
Assuming there are a limited number of vpn accounts that are to be used,
set up openconnect to use scripts in /usr/local/sbin that does what's
needed, and create scripts in /usr/local/bin that uses pkexec to run the
sbin scripts.
Don't allow any input from the user to be passed directly to the
openconnect command. If any user input is passed, it would require very
good filtering to prevent them passing something like
"configfilename='../../../dev/sda'"
or "configfilename='thefilename;rm -rf /'" instead of just a filename.
Regards, Dave Hodgins

Hi,

first I'd like to mention that I took a box which was not really needed,
and, in I repaired it easily and fast by rewriting the MBR via rescue
boot from installation DVD. So, no real damage occurred.

But the reason for mentioning this here is that one always can make
mistakes when passing options to programs.

The original authors of openconnect and vpnc should consider limiting
path and file to /run/vpn.pid or so, and filter away any attempt to write
to other locations ( '/', '..' ).

Due to the dangerous bugs pkexec showed up in the past makes me think of
some alternative ways.

Anyway, thanks!

Best regards,

Markus

[Markus Robert Kessler]

On Wed, 27 Sep 2023 15:51:26 -0400, Markus Robert Kessler

Post by Markus Robert Kessler
For years I am setting up sudo-based cisco vpnc vpn access, so that
"normal" users can open / close vpns without root password.
Now I did the same with openconnect.
This one also provides the option "--pid-file", which is handy, because
vpnc provides a small program called "vpnc-disconnect", which looks for
the pid hardcoded in /run/vpnc.pid. So, I set up openconnect to use the
same pid-file, and hence oepnconnect can be also terminated using
"vpnc- disconnect".
Well, this option looked suspicious to me from the beginning, and so I
had a look into the sources. There I saw something like "prefix" and
other fancy things around the pid-file, and so I thought this was to
"sanitize" user input.
But it was not.
I tried "openconnect --pid-file /dev/sda ..."
and, guess? -- Yes, the box did not boot anymore.
What makes me nervous is that every non-privileged user can do the
same. Vpnc seems to have the same security hole.
I am just thinking about recompile and rebuild the packages, where this
option is excluded and the pid file is hardcoded to, let's say /run/
vpnc.pid.
Any idea?

The openconnect binary is in /usr/sbin instead of /usr/bin because it's
intended to be restricted to people who can be trusted.
If I were trying to set it up so that untrusted regular users could
still start and stop it, look at something like mgaonline for how it
does it's stuff.
/usr/bin/mgaupdate uses pkexec to run /usr/libexec/mgaupdate with root
privileges.
Assuming there are a limited number of vpn accounts that are to be used,
set up openconnect to use scripts in /usr/local/sbin that does what's
needed, and create scripts in /usr/local/bin that uses pkexec to run the
sbin scripts.
Don't allow any input from the user to be passed directly to the
openconnect command. If any user input is passed, it would require very
good filtering to prevent them passing something like
"configfilename='../../../dev/sda'"
or "configfilename='thefilename;rm -rf /'" instead of just a filename.

Hi Dave,

meanwhile I found one more way to do this, without polkit:

The complete commandline to invoke openconnect along with all parameters
is being placed in a c file, for instance

#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <stdlib.h>

char *SHELL = "openconnect -b --pid-file /var/run/vpnc.pid -u USER [and so
on] SERVER";

void main ( void ) {
setreuid ( geteuid () , getuid () );
system ( SHELL );
}

This has to be compiled like
gcc openconnect-wrapper.c -o openconnect-wrapper

set to root:root 0700 and moved to, let's say /usr/sbin.
So, from the wrapper running sudoed root, the child process openconnect is
inheriting root rights also.

Users who should be able to start/stop the vpn simply get sudo right to
above file.

So, I even don't need to patch every newly published update to this rpm.

Best regards,

Markus

[Markus Robert Kessler]

Post by Markus Robert Kessler
For years I am setting up sudo-based cisco vpnc vpn access, so that
"normal" users can open / close vpns without root password.
Now I did the same with openconnect.
This one also provides the option "--pid-file", which is handy, because
vpnc provides a small program called "vpnc-disconnect", which looks for
the pid hardcoded in /run/vpnc.pid. So, I set up openconnect to use the
same pid-file, and hence oepnconnect can be also terminated using "vpnc-
disconnect".
Well, this option looked suspicious to me from the beginning, and so I
had a look into the sources. There I saw something like "prefix" and
other fancy things around the pid-file, and so I thought this was to
"sanitize" user input.
But it was not.
I tried "openconnect --pid-file /dev/sda ..."
and, guess? -- Yes, the box did not boot anymore.
What makes me nervous is that every non-privileged user can do the same.
Vpnc seems to have the same security hole.
I am just thinking about recompile and rebuild the packages, where this
option is excluded and the pid file is hardcoded to, let's say /run/
vpnc.pid.
Any idea?
Markus

After comparing to Raspbian OS I found out the following:

Raspbian OS / Debian allows to write to any location and any filename, as
long as either non-existing, or ending on '.pid'.

So, for instance it is not possible to write to /etc/passwd,
but it is possible to write to /run/openconnect.foo as long as it is not
there yet, and it is possible to overwrite /run/vpnc.pid if the former
openconnect process was 'pkill -9'-ed hence the file still exists.

Conclusio:

The source seems the same for the distros out there, but Debian has some
patches, preventing people from smashing their boxes by intention or by
accident.

Mageie (9 and most probably older ones) do not have such security means.

Markus