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

Bug #230208 reported by falstaff on 2008-05-14
258
Affects Status Importance Assigned to Milestone
openvpn (Ubuntu)
High
Martin Pitt
Feisty
Undecided
Unassigned
Gutsy
Undecided
Unassigned
Hardy
High
Martin Pitt
Intrepid
Undecided
Unassigned

Bug Description

After updating my System with the patch from USN-612-3, I deleted all my key files and regenerated them. But even after the recreation of the keys, openvpn always says:

May 14 10:42:18 localhost openvpn[13048]: ERROR: '/etc/openvpn/secret.key' is a known vulnerable key. See 'man openssl-vulnkey' for details.

# /usr/sbin/openssl-vulnkey /etc/openvpn/secret.key
indeed workes great! It returns Not blacklisted: .... and
# echo $?
says return value is 0.

I set verb to 10, and found out this in my syslog

May 14 10:42:18 localhost openvpn[13048]: SYSTEM return=256

Further investigation broght me the solutions... I found this _before_ the call of /usr/sbin/openssl-vulnkey -q /etc/openvpn/secret.key, so the process is running as nobody!

May 14 10:42:17 localhost openvpn[13048]: GID set to nogroup
May 14 10:42:17 localhost openvpn[13048]: UID set to nobody

And my key has apparently no access rights for nobody...

-rw------- 1 root root 887 2008-05-14 09:10 secret.key

So after chmod-ing the key file it worked like a charm! Can the test be done before going to nobody user? Doesnt make sens this way in my opinion...

falstaff (falstaff) wrote :
Martin Pitt (pitti) on 2008-05-14
Changed in openvpn:
assignee: nobody → pitti
importance: Undecided → Critical
status: New → In Progress
Martin Pitt (pitti) wrote :

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

Martin Pitt (pitti) wrote :

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.

Martin Pitt (pitti) wrote :

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!

Martin Pitt (pitti) wrote :

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

Changed in openvpn:
importance: Critical → High
Martin Pitt (pitti) wrote :

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.

Martin Pitt (pitti) wrote :

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

Martin Pitt (pitti) wrote :

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

falstaff (falstaff) wrote :

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

Martin Pitt (pitti) wrote :

Update for hardy uploaded.

Changed in openvpn:
assignee: nobody → pitti
importance: Undecided → High
status: New → Fix Committed
Martin Pitt (pitti) wrote :

Feisty and Gutsy updates prepared, tested, uploaded.

Changed in openvpn:
status: New → Fix Committed
Martin Pitt (pitti) wrote :

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

Changed in openvpn:
status: New → Fix Committed
status: In Progress → Fix Committed
Changed in openvpn:
assignee: nobody → jdstrand
assignee: jdstrand → nobody
Launchpad Janitor (janitor) wrote :

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

Launchpad Janitor (janitor) wrote :

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

Launchpad Janitor (janitor) wrote :

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

Changed in openvpn:
status: Fix Committed → Fix Released
status: Fix Committed → Fix Released
status: Fix Committed → Fix Released
Martin Pitt (pitti) wrote :

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.

Changed in openvpn:
status: Fix Committed → Fix Released
falstaff (falstaff) wrote :

Thanks! This fix work for me!

Frode M. Døving (frode) wrote :

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

Thierry Carrez (ttx) on 2009-08-19
Changed in openvpn (Ubuntu Intrepid):
status: New → Fix Released
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers