@MSGID: 1@dont-email.me> 7a158303
@REPLY: <op.2bygi20va3w0dxdave@hodgins.homeip.net>
e35b7b25
@REPLYADDR Markus Robert Kessler
<no_reply@dipl-ing-kessler.de>
@REPLYTO 2:5075/128 Markus Robert Kessler
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: 1@dont-email.me>
1@dont-email.me><op.2bygi20va3w0dxdave@hodgins.homeip.net>
an> @TZUTC: -0000
@PID: Pan/0.145 (Duplicitous mercenary valetism;
d7e168a git.gnome.org/pan2)
@TID: FIDOGATE-5.12-ge4e8b94
On Wed, 27 Sep 2023 20:19:40 -0400 David W. Hodgins wrote:

> On Wed, 27 Sep 2023 15:51:26 -0400, Markus Robert Kessler
> <no_reply@dipl-ing-kessler.de> wrote:
> 
>> 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


-- 
Please reply to group only.
For private email please use http://www.dipl-ing-kessler.de/email.htm
--- Pan/0.145 (Duplicitous mercenary valetism; d7e168a git.gnome.org/pan2)
 * Origin: A noiseless patient Spider (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5075/128
@PATH: 5075/128 5020/1042 4441