Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#88 closed Bug / Defect (notabug)

management-forget-disconnect crashes process

Reported by: bwess Owned by: David Sommerseth
Priority: minor Milestone:
Component: Management Version: OpenVPN 2.1.4 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc:

Description

Verified on the Windows version of openvpn.
Easy to test since openvpn is on hold.

  1. Add the following options to a client config file:

management 127.0.0.1 1194
management-hold
management-query-passwords
management-forget-disconnect
auth-retry interact

  1. Start openvpn as a service.
  2. Connect to the management interface (telnet 127.0.0.1 1194).
  3. Disconnect from the management interface (exit).
  4. That openvpn process crashes reliably, but only if management-forget-disconnect is used.

Change History (8)

comment:1 Changed 13 years ago by David Sommerseth

Are you able to test this config on a Linux or *BSD box as well? That could help narrow it down to if it is a Windows only or a more generic bug.

I tried using exactly the same options you used on Fedora 14 with openvpn 'allmerged' (based on commit c0f8e9f19842), and it doesn't crash at all for me.

comment:2 Changed 13 years ago by bwess

I did a quick test with "OpenVPN 2.1.1 x86_64-unknown-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] built on Jul 5 2010" included in openSUSE 11.3, it also happens:

Feb 22 17:34:07 hostname kernel: [26618.966184] openvpn[7008]: segfault at 10 ip 00007f46a552cf05 sp 00007fffc30f3b10 error 4 in libpkcs11-helper.so.1.0.0[7f46a551f000+1a000]

comment:3 Changed 13 years ago by David Sommerseth

Hmmm ... Would it be possible to get a complete configuration files, at least for the client. Server would also help to try to reproduce this issue.

I just tried openvpn-2.1.1 on Fedora 14, and again, no issues.

Tue Feb 22 18:10:28 2011 OpenVPN 2.1.1 x86_64-redhat-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] built on Jan 5 2010

comment:4 Changed 13 years ago by David Sommerseth

If I had opened my eyes a little bit more ... I would have noticed that your crash refers to libpkcs11-helper.so.1.0.0.

Still it would be useful to see config files. Another thing, can you please start your openvpn session via gdb and take out a backtrace? See https://community.openvpn.net/openvpn/wiki/TesterDocumentation#Debugging for more info. That can help more to figure out if this is an OpenVPN problem or a libpkcs11 issue. If doable, please consider to enable core dump files and send it to us. You can send it to me directly, to preserve your privacy (dazo{a}users.sourceforge.net)

comment:5 Changed 13 years ago by David Sommerseth

Owner: set to David Sommerseth
Status: newaccepted

An update!

I've managed to reproduce it with Jan Just Keijser's help. It is related to the pkcs11-helper library. My error was that I did 'hold release' before exiting. But by not doing 'hold release' and just do 'exit' directly, then it does crash *if* the PKCS#11 feature is enabled in OpenVPN.

This issue has been reported to the OpenSC developers.

What OpenVPN does is to call pkcs11h_logout() before the pkcs11 environment have been initialised correctly in this situation. Which is comparable to doing this:

#include <pkcs11-helper-1.0/pkcs11h-openssl.h>

int main() {
          pkcs11h_logout();
          return 0;
}

And this gives the following backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x00000036a300ca45 in pkcs11h_logout () at pkcs11h-core.c:1069
1069			current_session = _g_pkcs11h_data->sessions;
Missing separate debuginfos, use: debuginfo-install zlib-1.2.5-2.fc14.x86_64
(gdb) bt
#0  0x00000036a300ca45 in pkcs11h_logout () at pkcs11h-core.c:1069
#1  0x000000000040060d in main ()

When this error happens in OpenVPN, the backtrace looks like this:

#0  0x00000036a300ca45 in pkcs11h_logout () at pkcs11h-core.c:1069
#1  0x000000000042f049 in pkcs11_logout () at pkcs11.c:385
#2  0x000000000045112b in ssl_purge_auth () at ssl.c:320
#3  0x000000000041c6f5 in man_reset_client_socket (man=0x8a1800, exiting=0) at manage.c:1560
#4  0x000000000041efda in man_read (man=0x8a1800) at manage.c:1717
#5  management_io (man=0x8a1800) at manage.c:2414
#6  0x000000000041f0f3 in man_standalone_event_loop (man=0x8a1800, signal_received=0x7fffffffd7ec, expire=<value optimized out>)
    at manage.c:2518
#7  0x000000000041f33d in management_hold (man=0x8a1800) at manage.c:2744
#8  0x0000000000414ea6 in do_hold (c=0x7fffffffd870) at init.c:1405
#9  0x00000000004151ad in open_management (c=0x7fffffffd870) at init.c:2753
#10 0x000000000042fc1a in main (argc=5, argv=0x7fffffffe628) at openvpn.c:193

I'll look more carefully into the OpenVPN code to see if there is a way how to avoid this situation in OpenVPN too. But the core issue is in the pkcs11-helper library, in my opinion.

comment:6 Changed 13 years ago by David Sommerseth

Resolution: notabug
Status: acceptedclosed

Things happens quickly today ... http://thread.gmane.org/gmane.comp.encryption.opensc.devel/12122

As this is now confirmed as a pkcs11-helper bug, I'm closing this ticket as "notabug", as it is not an issue in OpenVPN.

comment:7 Changed 13 years ago by Samuli Seppänen

Latest preview of OpenVPN 2.2-rc contains a fixed version of pkcs11-helper. Could you verify that it fixes this issue?

comment:8 Changed 13 years ago by bwess

Tested with
"OpenVPN 2.2-RC Win32-MSVC++ [SSL] [LZO2] built on Feb 28 2011"
and verified that the problem does *not* occur anymore.
Thanks

Note: See TracTickets for help on using tickets.