Mailing List Archive: vpnc doesn't work with libgcrypt build with caps support

vpnc doesn't work with libgcrypt build with caps support

May 1, 2013, 6:27 AM

Post #1 of 5 (2905 views)

Hello,

I would like to forward to you a bug report I received
(https://bugs.gentoo.org/show_bug.cgi?id=467744):

Problem:

net-misc/vpnc-0.5.3_p527 doesn't connect to server with
dev-libs/libgcrypt-1.5.2[caps] (the "caps" USE flag was added yesterday,
by the way):

----
# vpnc /etc/vpnc/vpnc.conf --debug 3

vpnc version 0.5.3
hex_test: 00010203

S1 init_sockaddr
[2013-04-28 21:41:02]

S2 make_socket
[2013-04-28 21:41:03]
vpnc: Error binding to source port. Try '--local-port 0'
Failed to bind to 0.0.0.0:500: Permission denied

## Try an unprivileged port
# vpnc /etc/vpnc/vpnc.conf --debug 3 --local-port 10942

vpnc version 0.5.3
hex_test: 00010203

S1 init_sockaddr
[2013-04-28 21:41:59]

S2 make_socket
[2013-04-28 21:42:00]

S3 setup_tunnel
[2013-04-28 21:42:00]
using interface
vpnc: can't initialise tunnel interface: Operation not permitted
----

With dev-libs/libgcrypt-1.5.2[-caps] it works correctly.

I did a bit debugging, and found vpnc calls
"gcry_control(GCRYCTL_INIT_SECMEM, 16384, 0);" immediately after it
starts, but this command, according to libgcrypt manual, drops
privileges of the process. If libgcrypt is compiled without caps
support, it will only drop the privileges for setuid processes, which
doesn't affect vpnc because it runs as root directly. Nonetheless, when
it's compiled with caps support, it drops the privileges with libcap,
causing vpnc to lose the privilege to bind to privileged ports,
establish a tunnel, etc., therefore entirely breaking its operation.

Suggested solution:

The most direct way to let vpnc depends on || (
>=dev-libs/libgcrypt-1.5.2[-caps] <dev-libs/libgcrypt-1.5.2 ).

I don't know if patching libgcrypt will help, but it could cause
security issues, and will affect other software using the library as well.

On the vpnc side, my guess is vpnc at least relies pretty much on root
privileges until the tunnel is established and the up script is
executed, and vpnc may require those libgcrypt things for establishing
the tunnel. I tried moving the GCRYCTL_INIT_SECMEM line into the later
stages of vpnc's operation, only to see a different "Operation not
permitted". I didn't look further and I do not know if vpnc actually
needs SECMEM. Of course, it's better to let the upstream works on the
issue, but I'm not completely sure if the upstream is alive. And
libcrypt already has caps support since 2003, so the problem probably
has been there for ages without a fix from upstream.

Do you see any chance to fix this issue?

Regards,

Justin

Re: vpnc doesn't work with libgcrypt build with caps support [ In reply to ]

borneo.antonio at gmail

May 1, 2013, 9:48 AM

Post #2 of 5 (2823 views)

Permalink

Hi Justin,

On Wed, May 1, 2013 at 9:27 PM, Justin <jlec@gentoo.org> wrote:
> Hello,
>
> I would like to forward to you a bug report I received
> (https://bugs.gentoo.org/show_bug.cgi?id=467744):
>
><snip>
>
> With dev-libs/libgcrypt-1.5.2[-caps] it works correctly.
>
> I did a bit debugging, and found vpnc calls
> "gcry_control(GCRYCTL_INIT_SECMEM, 16384, 0);" immediately after it
> starts, but this command, according to libgcrypt manual, drops
> privileges of the process. If libgcrypt is compiled without caps
> support, it will only drop the privileges for setuid processes, which
> doesn't affect vpnc because it runs as root directly. Nonetheless, when
> it's compiled with caps support, it drops the privileges with libcap,
> causing vpnc to lose the privilege to bind to privileged ports,
> establish a tunnel, etc., therefore entirely breaking its operation.

Well spotted!

>
> Suggested solution:
>
> The most direct way to let vpnc depends on || (
>>=dev-libs/libgcrypt-1.5.2[-caps] <dev-libs/libgcrypt-1.5.2 ).

In the long term it will require a special libgcrypt for vpnc only!
I'm not sure this is the right way.

> I don't know if patching libgcrypt will help, but it could cause
> security issues, and will affect other software using the library as well.
>
> On the vpnc side, my guess is vpnc at least relies pretty much on root
> privileges until the tunnel is established and the up script is
> executed, and vpnc may require those libgcrypt things for establishing
> the tunnel.

Root privileges are required also at vpnc exit to resume initial
routing table and DNS and to remove tun/tap device. Dropping
privileges is not correct.
Probably the solution is to split vpnc is two tasks, one that keeps
root privileges and another that uses GCRYCTL_INIT_SECMEM. But it's a
major rework!

> I tried moving the GCRYCTL_INIT_SECMEM line into the later
> stages of vpnc's operation, only to see a different "Operation not
> permitted". I didn't look further and I do not know if vpnc actually
> needs SECMEM. Of course, it's better to let the upstream works on the
> issue, but I'm not completely sure if the upstream is alive. And
> libcrypt already has caps support since 2003, so the problem probably
> has been there for ages without a fix from upstream.
>
> Do you see any chance to fix this issue?

I'm not anymore active in vpnc, since all my accounts with Cisco or
Nortel vpn are over.
I even cannot test completely a new binary.

Digging with google, one possible solution is by stop using secure
memory and use the standard allocator:
- gcry_control(GCRYCTL_INIT_SECMEM, 16384, 0);
+ gcry_control(GCRYCTL_DISABLE_SECMEM);
This could have drawbacks in terms of security. Need deeper investigation.

In mean time would be good if you could test the code change above.

Best Regards,
Antonio
_______________________________________________
vpnc-devel mailing list
vpnc-devel@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/

Re: vpnc doesn't work with libgcrypt build with caps support [ In reply to ]

jlec at gentoo

May 2, 2013, 3:57 AM

Post #3 of 5 (2803 views)

Permalink

Hello Antonio,

> Probably the solution is to split vpnc is two tasks, one that keeps
> root privileges and another that uses GCRYCTL_INIT_SECMEM. But it's a
> major rework!
>

I would like someone to pick up this idea and do the work.

> Digging with google, one possible solution is by stop using secure
> memory and use the standard allocator:
> - gcry_control(GCRYCTL_INIT_SECMEM, 16384, 0);
> + gcry_control(GCRYCTL_DISABLE_SECMEM);
> This could have drawbacks in terms of security. Need deeper investigation.
>
> In mean time would be good if you could test the code change above.
>

I tried this and it works. How severe would you consider the security
reduction?
Is this something one could do or rather a no-go?

Thanks for the quick response,
Justin

Re: vpnc doesn't work with libgcrypt build with caps support [ In reply to ]

pyxlcy at gmail

May 2, 2013, 9:10 AM

Post #4 of 5 (2799 views)

Permalink

Hello Antonio Borneo and Justin Lecher,

I'm the original reporter of the bug on Gentoo side. Justin Lecher told
me to continue the discussion here.

> Root privileges are required also at vpnc exit to resume initial
> routing table and DNS and to remove tun/tap device. Dropping
> privileges is not correct.

Oh, I remember openvpn supports dropping privileges after establishing
tunnel, so I thought vpnc could as well. I didn't look into how openvpn
achieved that, though.

> In the long term it will require a special libgcrypt for vpnc only!
> I'm not sure this is the right way.

It sounds like the easiest option, but Justin apparently doesn't like it
("libgcrypt is not an option from the gentoo packaging guideline
perspective.")

> Probably the solution is to split vpnc is two tasks, one that keeps
> root privileges and another that uses GCRYCTL_INIT_SECMEM. But it's a
> major rework!

Yeah, sounds pretty tricky indeed.

> I'm not anymore active in vpnc, since all my accounts with Cisco or
> Nortel vpn are over.
> I even cannot test completely a new binary.

I might be able to provide a Cisco VPN account for testing, but probably
only during very limited hours in a day, if you really really can't find
a better way to test this.

> Digging with google, one possible solution is by stop using secure
> memory and use the standard allocator:
> - gcry_control(GCRYCTL_INIT_SECMEM, 16384, 0);
> + gcry_control(GCRYCTL_DISABLE_SECMEM);
> This could have drawbacks in terms of security. Need deeper investigation.
>
> In mean time would be good if you could test the code change above.

I could confirm the trick works in my brief test with
net-misc/vpnc-0.5.3_p527.

With my severely limited comprehension of the situation, what I could
see regarding libgcrypt's secure memory implementation are:

1. Secure memory is (usually) allocated via mmap() with MAP_PRIVATE |
MAP_ANONYMOUS (src/secmem.c, init_pool()), while standard memory
seemingly are allocated from the heap with malloc().

2. They are locked into memory (never swapped into disk) via mlock()
(src/secmem.c, lock_pool()). Indeed, once something gets written into a
traditional hard drive, it's often recoverable in the hands of an
expert.

3. Secure memory are guaranteed to be overwritten with zero when freed
(src/secmem.c, _gcry_secmem_free_internal()).

For a casual user (like me, who uses VPN as a tunnel to get around the
Great Firewall of China) I don't think this is too huge an issue, but it
could very well be a bad thing for those using it to access private
LANs, I guess.

Regards,
Richard Grenville

On Thu, May 02, 2013 at 12:57:47PM +0200, Justin wrote:
> Hello Antonio,
>
> > Probably the solution is to split vpnc is two tasks, one that keeps
> > root privileges and another that uses GCRYCTL_INIT_SECMEM. But it's a
> > major rework!
> >
>
> I would like someone to pick up this idea and do the work.
>
> > Digging with google, one possible solution is by stop using secure
> > memory and use the standard allocator:
> > - gcry_control(GCRYCTL_INIT_SECMEM, 16384, 0);
> > + gcry_control(GCRYCTL_DISABLE_SECMEM);
> > This could have drawbacks in terms of security. Need deeper investigation.
> >
> > In mean time would be good if you could test the code change above.
> >
>
> I tried this and it works. How severe would you consider the security
> reduction?
> Is this something one could do or rather a no-go?
>
> Thanks for the quick response,
> Justin
>

> _______________________________________________
> vpnc-devel mailing list
> vpnc-devel@unix-ag.uni-kl.de
> https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
> http://www.unix-ag.uni-kl.de/~massar/vpnc/

Re: vpnc doesn't work with libgcrypt build with caps support [ In reply to ]

fschlich at zedat

May 6, 2013, 12:06 AM

Post #5 of 5 (2785 views)

Permalink

Hi Antonio,

> > I didn't look further and I do not know if vpnc actually
> > needs SECMEM. Of course, it's better to let the upstream works on the
> > issue, but I'm not completely sure if the upstream is alive. And
> > libcrypt already has caps support since 2003, so the problem probably
> > has been there for ages without a fix from upstream.
> >
> > Do you see any chance to fix this issue?
>
> I'm not anymore active in vpnc, since all my accounts with Cisco or
> Nortel vpn are over.
> I even cannot test completely a new binary.

that sounds a little worrying!

While vpnc as-is works reasonably well for many people and ipsec-based VPN
generally seems to be on the decline (at least for Cisco), so lots of
upstream development may not be needed or worthwhile any more, I think
there still needs to be someone who picks up the patches that get sent
to the mailing list. Thorough testing may not be necessary or can be
done by the bug reporters / patch submitters / SVN version users, but it
would be good to keep the upstream repository as a central place to
collect contributions.

Would you (or anybody else with commit access) stay around to do
something like that?

Florian
- maintaining vpnc in Debian -
_______________________________________________
vpnc-devel mailing list
vpnc-devel@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/

Mailing List Archive

Attached Files:

Attached Files:

Attached Files: