[PATCH] security issue in CSD implementation

Adam Piątyszek adam.piatyszek at gmail.com
Fri Aug 21 16:38:13 EDT 2009


Hi Antonio and David,

Please find the attached patch that adds a separate option 
--setuid-csd=USER for dropping root privileges during CSD script execution.

You will find this patch in my cloned openconnect-csd2 repository:
http://git.infradead.org/users/ediap/openconnect-csd2.git

Thanks,
/Adam


* Antonio Borneo [08.08.2009 07:24]:
> I was already thinking that is not correct to use same -U user to drop
> priviledges to CSD and to mainloop connection.
> Anyway, seem that using non root user with -U, openconnect does not
> have priviledges anymore to run vpnc-script at exit.
> We need a fix for this case too.
> 
> Best Regards,
> Antonio Borneo
> 
> On Sat, Aug 8, 2009 at 5:23 AM, Adam Piątyszek<adam.piatyszek at gmail.com> wrote:
>> Hi Antonio,
>>
>> I have briefly tested your latest patch and have one observation regarding
>> the "-U" option. When I use a non-root user for the -U argument, I have
>> problems when disconnecting from VPN by stopping the openconnect client:
>>
>> Connected tun0 as 172.30.64.195, using SSL
>> Established DTLS connection
>> ^CSend BYE packet: Client received SIGINT
>> RTNETLINK answers: Operation not permitted
>> Cannot open "/proc/sys/net/ipv4/route/flush"
>> RTNETLINK answers: Operation not permitted
>> Cannot open "/proc/sys/net/ipv4/route/flush"
>> RTNETLINK answers: Operation not permitted
>> Cannot open "/proc/sys/net/ipv4/route/flush"
>> RTNETLINK answers: Operation not permitted
>> Cannot open "/proc/sys/net/ipv4/route/flush"
>> RTNETLINK answers: Operation not permitted
>> Cannot open "/proc/sys/net/ipv4/route/flush"
>> RTNETLINK answers: Operation not permitted
>> Cannot open "/proc/sys/net/ipv4/route/flush"
>> RTNETLINK answers: Operation not permitted
>> Cannot open "/proc/sys/net/ipv4/route/flush"
>> RTNETLINK answers: Operation not permitted
>> Cannot open "/proc/sys/net/ipv4/route/flush"
>> RTNETLINK answers: Operation not permitted
>> Cannot open "/proc/sys/net/ipv4/route/flush"
>> RTNETLINK answers: Operation not permitted
>> Cannot open "/proc/sys/net/ipv4/route/flush"
>> RTNETLINK answers: Operation not permitted
>> Cannot open "/proc/sys/net/ipv4/route/flush"
>> RTNETLINK answers: Operation not permitted
>> Cannot open "/proc/sys/net/ipv4/route/flush"
>> RTNETLINK answers: Operation not permitted
>> Cannot open "/proc/sys/net/ipv4/route/flush"
>> RTNETLINK answers: Operation not permitted
>> Cannot open "/proc/sys/net/ipv4/route/flush"
>>
>> I use vpnc-script talking with resolvconf and also dnmasq as a local caching
>> DNS server. The problem is that the nameservers from VPN network are not
>> removed from dnsmasq configuration files and DNS queries no longer work.
>>
>> If I run openconnect without "-U" option (as root) and later stop it with
>> Ctrl+C, the settings configured by the vpnc-script are correctly removed and
>> DNS queries uses my ISP nameservers.
>>
>> Therefore I would prefer to drop privileges only for running the CSD script,
>> but do not drop it after successful connection. What do you think?
>>
>> BR,
>> /Adam
>>
>>
>> * Antonio Borneo [06.08.2009 15:49]:
>>> Glad to be the first one posting in the list.
>>>
>>> David has just integrated in git a first working support for CSD. Thanks!
>>>
>>> In the project's webpage he correctly defines CSD as "idiocy".
>>> CSD seems also a badly written code. It's easy to notice that in the
>>> (latest?) version 3.4.2048.0, the binary csd.linux.i386 doesn't even
>>> correctly "copy" the command line to the following binary hostscan.
>>> Sigh!
>>> Anyway, it's clear we cannot trust CSD's binary; it's better to
>>> confine its execution.
>>>
>>> Also, some of us runs OpenConnect as root, in order to set IP and
>>> routing with a script.
>>> Currently, the same root user also runs CSD binary... too dangerous!
>>>
>>> Patch in attachment drops privileges before running CSD code.
>>> It requires a valid user provided on the command line with "-U"
>>> Pay attension at the home directory specified in /etc/passwd for such
>>> user:
>>> - home must exist;
>>> - the user must have write privileges;
>>> In fact, CSD creates and writes files either in such home directory
>>> (within sub-directory ~/.cisco) and in the directory ${HOME}/.cisco
>>> (where HOME is taken from environment).
>>> So, don't select a user, e.g. like "nobody", that have entry "/" as
>>> home in /etc/passwd.
>>> Eventually, create an entry for a "csd" user
>>> csd:x:1500:99:CSD confinement:/tmp:/sbin/nologin
>>>
>>> Should we put these considerations in the man-page, or is better
>>> adding a README-CSD?
>>> Should we think about additional code to verify if the home directory
>>> has right properties?
>>>
>>> David,
>>> for the patch in attachment you can use
>>> Signed-off-by: Antonio Borneo <borneo.antonio at gmail.com>
>>>
>>> Best Regards,
>>> Antonio Borneo

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 0001-Drop-root-privileges-during-execution-of-CSD-script.patch
URL: <http://bombadil.infradead.org/pipermail/openconnect-devel/attachments/20090821/a334e85b/attachment.el>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3336 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://bombadil.infradead.org/pipermail/openconnect-devel/attachments/20090821/a334e85b/attachment.bin>


More information about the openconnect-devel mailing list