[openbsd] openvpn 2.3.6 segfault when dns resolving fails

[jirib]

IIRC i had blocked outgoing dns on my fw and thus openvpn could not resolve remote openvpn server hostname.

# openvpn --config /etc/openvpn/ovpn-brq-udp-x86_64.conf  
Fri Apr 10 21:40:22 2015 OpenVPN 2.3.6 x86_64-unknown-openbsd5.7 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Mar 24 2015
Fri Apr 10 21:40:22 2015 library versions: LibreSSL 2.1, LZO 2.09
Enter Auth Username:jbelka
Enter Auth Password:
Fri Apr 10 21:40:30 2015 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Fri Apr 10 21:40:30 2015 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Fri Apr 10 21:40:30 2015 PLUGIN_INIT: POST /usr/local/lib/openvpn/plugins/openvpn-plugin-down-root.so '[/usr/local/lib/openvpn/plugins/openvpn-plugin-down-root.so] [/etc/openvpn/ovpn-brq-udp-client.down]' intercepted=PLUGIN_UP|PLUGIN_DOWN 
Fri Apr 10 21:40:30 2015 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1360)
Fri Apr 10 21:40:30 2015 Socket Buffers: R=[41600->65536] S=[9216->65536]
Segmentation fault (core dumped)
...
Core was generated by `openvpn'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00000bc6a1c747f9 in resolve_remote (sock=0xbc8e1ed9200, phase=1, remote_dynamic=0x0, signal_received=0x0) at /home/jirib/openbsd/pobj/openvpn-2.3.6/openvpn-2.3.6/src/openvpn/socket.c:1270
1270                              sock->info.lsa->remote.addr.in6 = *((struct sockaddr_in6*)(ai->ai_addr));
(gdb) bt
#0  0x00000bc6a1c747f9 in resolve_remote (sock=0xbc8e1ed9200, phase=1, remote_dynamic=0x0, signal_received=0x0) at /home/jirib/openbsd/pobj/openvpn-2.3.6/openvpn-2.3.6/src/openvpn/socket.c:1270
#1  0x00000bc6a1c74eaf in link_socket_init_phase1 (sock=0xbc8e1ed9200, connection_profiles_defined=false, local_host=0x0, local_port=0, remote_host=0xbc8ff7ca0a8 "ovpn-brq.redhat.com", remote_port=443, proto=1, 
    mode=0, accept_from=0x0, http_proxy=0x0, socks_proxy=0x0, gremlin=0, bind_local=false, remote_float=false, inetd=0, lsa=0x7f7fffff10b0, ipchange_command=0x0, plugins=0xbc95050e000, 
    resolve_retry_seconds=1000000000, connect_retry_seconds=5, connect_timeout=10, connect_retry_max=0, mtu_discover_type=-1, rcvbuf=65536, sndbuf=65536, mark=0, sockflags=0)
    at /home/jirib/openbsd/pobj/openvpn-2.3.6/openvpn-2.3.6/src/openvpn/socket.c:1493
#2  0x00000bc6a1c230f1 in do_init_socket_1 (c=0x7f7fffff0a60, mode=0) at /home/jirib/openbsd/pobj/openvpn-2.3.6/openvpn-2.3.6/src/openvpn/init.c:2632
#3  0x00000bc6a1c247df in init_instance (c=0x7f7fffff0a60, env=0xbc923afc1f0, flags=4) at /home/jirib/openbsd/pobj/openvpn-2.3.6/openvpn-2.3.6/src/openvpn/init.c:3416
#4  0x00000bc6a1c242ff in init_instance_handle_signals (c=0x7f7fffff0a60, env=0xbc923afc1f0, flags=4) at /home/jirib/openbsd/pobj/openvpn-2.3.6/openvpn-2.3.6/src/openvpn/init.c:3245
#5  0x00000bc6a1c42708 in tunnel_point_to_point (c=0x7f7fffff0a60) at /home/jirib/openbsd/pobj/openvpn-2.3.6/openvpn-2.3.6/src/openvpn/openvpn.c:70
#6  0x00000bc6a1c42b32 in openvpn_main (argc=3, argv=0x7f7fffff1778) at /home/jirib/openbsd/pobj/openvpn-2.3.6/openvpn-2.3.6/src/openvpn/openvpn.c:250
#7  0x00000bc6a1c42c82 in main (argc=3, argv=0x7f7fffff1778) at /home/jirib/openbsd/pobj/openvpn-2.3.6/openvpn-2.3.6/src/openvpn/openvpn.c:325

$ openvpn --version
OpenVPN 2.3.6 x86_64-unknown-openbsd5.7 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Mar 24 2015
library versions: LibreSSL 2.1, LZO 2.09
Originally developed by James Yonan
Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@openvpn.net>
Compile time defines: enable_crypto=yes enable_crypto_ofb_cfb=yes enable_debug=yes enable_def_auth=yes enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=needless enable_fragment=yes enable_gtk_doc=no enable_http_proxy=yes enable_iproute2=no enable_libtool_lock=yes enable_lzo=yes enable_lzo_stub=no enable_management=yes enable_multi=yes enable_multihome=yes enable_pam_dlopen=no enable_password_save=yes enable_pedantic=no enable_pf=yes enable_pkcs11=no enable_plugin_auth_pam=no enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_silent_rules=no enable_small=no enable_socks=yes enable_ssl=yes enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=no enable_win32_dll=yes enable_x509_alt_username=no with_crypto_library=openssl with_gnu_ld=no with_mem_check=no with_plugindir='$(libdir)/openvpn/plugins' with_sysroot=no

$ sysctl kern.version                                                                                                                                                                                             
kern.version=OpenBSD 5.7-current (GENERIC.MP) #903: Thu Apr  2 13:47:34 MDT 2015
    deraadt@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

[Gert Döring]

Does this need firewalling, or will "connect to hostname that does not exist" exhibit the same issue? Or "use a resolver that does not answer" (like, putting an unsused address in /etc/resolv.conf)?

It seems to be somewhere in our handling of getaddrinfo() error codes, but I'm too busy right now to setup a system with firewalling and all to reproduce.

Does it happen with OpenVPN git master as well (which has completely reworked address resolving)? Is this for an IPv4 or IPv6 server (2.3.x explicitely queries for one address family only, git master does "give me all there is")?

Arne, any quick idea?

[Gert Döring]

So, this might actually have been fixed already - 2.3.7 has a fix for bug #276, which is in the same category - "unexpected events" in openvpn_getaddrinfo() not being handled properly.

@jirib, could you please re-test with 2.3.8, or at least provide answers to my questions from 7 months ago? We're all for fixing bugs, but stuff we don't experience takes much longer to diagnose if we don't understand the precise circumstances. thanks.

[tct]

No answer for 4 years -- Closing.

I'll try to test this myself soon.