OpenVPN doesn't start after USN-612-3: New key is accused to be vulnerable

For the record, the current version works correctly with TLS. I tested both static ifconfig and client/server mode.

Could you please attach your configuration file? I tried this with PSKs, and it works for me as well:

  -rw------- 1 martin martin 636 2008-05-14 12:00 key

(not accessible to nobody/nogroup)

----- vpn-tick-psk.conf -----
remote tick.local
dev tun
ifconfig 10.99.0.1 10.99.0.2

user nobody
group nogroup

secret /home/martin/key
--------------------------------------

$ sudo openvpn --config vpn-tick-psk.conf
[...]
Wed May 14 12:02:21 2008 /usr/sbin/openvpn-vulnkey -q /home/martin/key
Wed May 14 12:02:21 2008 TUN/TAP device tun0 opened
Wed May 14 12:02:21 2008 ifconfig tun0 10.99.0.1 pointopoint 10.99.0.2 mtu 1500
Wed May 14 12:02:21 2008 GID set to nogroup
Wed May 14 12:02:21 2008 UID set to nobody
[...]

So for this configuration, the key is checked before dropping privileges.

Oh, from the log it rather seems you use SSL certificates and TLS, not pre-shared keys? So /etc/openvpn/secret.key is an SSL secret key, not a pre-shared one?

That's the configuration I tested first (server, multi-client, TLS), and it worked for me as well. I'll try some further variations until you reply.

Thank you!

Downgrading severity a bit, since it does not affect all systems.

Ah, I can reproduce it now with

-------------------
dev tun
server 10.99.0.0 255.255.255.0

user nobody
group nogroup

dh /usr/share/doc/openvpn/examples/sample-keys/dh1024.pem
ca /etc/ssl/certs/piware-ca.pem
cert /etc/ssl/certs/piware-desktop.pem
key /etc/ssl/private/piware-desktop.pem
--------------------

As soon as the first client connects, the openvpn server tries to verify the SSL key again, which fails.

This patch fixes this bug. I tested it with all possible modes (PSK, TLS with static IPs, TLS with client/server mode). They all

 * produce a working VPN with a valid key
 * check the secret key on startup
 * fail on startup if the key is invalid (using /usr/share/doc/openvpn-blacklist/examples/bad.key)
 * fail on startup if the key file does not exist

Now do the same check for the static case, too. Not actually required, but in the spirit of defensiveness.

Yes I use SSL certificates... Sorry for not writing back, was at lunch... Thanks!

Update for hardy uploaded.

Feisty and Gutsy updates prepared, tested, uploaded.

I will copy hardy-security over to hardy-updates and intrepid once it is published.

This bug was fixed in the package openvpn - 2.1~rc7-1ubuntu3.2

---------------
openvpn (2.1~rc7-1ubuntu3.2) hardy-security; urgency=low

  * init.c: Do not attempt to verify the key file with openvpn-vulnkey if it
    is not accessible (any more). This happens when using the 'user', 'group',
    or 'chroot' options in multi-client mode, and the SSL key file thus
    becomes unreadable from the second time on. If the key file is not
    accessible at the very start, this is already handled anyway, so we can
    safely ignore this condition. (LP: #230208)
    Note that this is not an issue when using pre-shared keys
    (do_init_crypto_static(), since multi-client mode only works with TLS.
    However, we also check it here just to be on the safe side.

 -- Martin Pitt <email address hidden> Wed, 14 May 2008 12:57:19 +0200

This bug was fixed in the package openvpn - 2.0.9-8ubuntu0.2

---------------
openvpn (2.0.9-8ubuntu0.2) gutsy-security; urgency=low

  * init.c: Do not attempt to verify the key file with openvpn-vulnkey if it
    is not accessible (any more). This happens when using the 'user', 'group',
    or 'chroot' options in multi-client mode, and the SSL key file thus
    becomes unreadable from the second time on. If the key file is not
    accessible at the very start, this is already handled anyway, so we can
    safely ignore this condition. (LP: #230208)
    Note that this is not an issue when using pre-shared keys
    (do_init_crypto_static(), since multi-client mode only works with TLS.
    However, we also check it here just to be on the safe side.

 -- Martin Pitt <email address hidden> Wed, 14 May 2008 13:35:35 +0200

This bug was fixed in the package openvpn - 2.0.9-5ubuntu0.2

---------------
openvpn (2.0.9-5ubuntu0.2) feisty-security; urgency=low

  * init.c: Do not attempt to verify the key file with openvpn-vulnkey if it
    is not accessible (any more). This happens when using the 'user', 'group',
    or 'chroot' options in multi-client mode, and the SSL key file thus
    becomes unreadable from the second time on. If the key file is not
    accessible at the very start, this is already handled anyway, so we can
    safely ignore this condition. (LP: #230208)
    Note that this is not an issue when using pre-shared keys
    (do_init_crypto_static(), since multi-client mode only works with TLS.
    However, we also check it here just to be on the safe side.

 -- Martin Pitt <email address hidden> Wed, 14 May 2008 13:41:04 +0200

2008-05-15 05:59:28 INFO FROM: Primary Archive for Ubuntu: hardy-UPDATES
2008-05-15 05:59:28 INFO TO: Primary Archive for Ubuntu: intrepid-RELEASE
2008-05-15 05:59:28 INFO Copy candidates:
2008-05-15 05:59:28 INFO openvpn 2.1~rc7-1ubuntu3.2 in hardy
2008-05-15 05:59:28 INFO openvpn 2.1~rc7-1ubuntu3.2 in hardy amd64
2008-05-15 05:59:28 INFO openvpn 2.1~rc7-1ubuntu3.2 in hardy hppa
2008-05-15 05:59:28 INFO openvpn 2.1~rc7-1ubuntu3.2 in hardy i386
2008-05-15 05:59:28 INFO openvpn 2.1~rc7-1ubuntu3.2 in hardy ia64
2008-05-15 05:59:28 INFO openvpn 2.1~rc7-1ubuntu3.2 in hardy lpia
2008-05-15 05:59:28 INFO openvpn 2.1~rc7-1ubuntu3.2 in hardy powerpc
2008-05-15 05:59:28 INFO openvpn 2.1~rc7-1ubuntu3.2 in hardy sparc
2008-05-15 05:59:28 INFO 8 packages successfully copied.

Thanks! This fix work for me!

I had the same issue, and can now confirm that it works with this fix. Thanks!