Re: [Openvpn-devel] [bug report] DOS: openvpn 2.0.2 segfaults on Solaris 9.

Tue, 01 Nov 2005 02:49:44 -0800 

On Montag, Okt 31, 2005, at 22:06 Europe/Berlin, James Yonan wrote:


On Mon, 31 Oct 2005, [ISO-8859-1] Marc Brünink wrote:



On Montag, Okt 31, 2005, at 17:26 Europe/Berlin, Giancarlo Razzolini
wrote:


Marc Brünink wrote:

Hi list,
I'm posting this there in case someone already fixed it or is disposed 
to fix it :-)
First of all: OpenVPN is great! Thanks for your work!.
Second of all: I've encounterd a reproducible bug :-(
I'm running
OpenVPN 2.0.2 sparc-sun-solaris2.9 [SSL] [LZO] built on Oct 17 2005
on a
SunOS sun 5.9 Generic_112233-12 sun4u sparc SUNW,Sun-Fire-V240
machine. OpenVPN is running in tcp server mode. Everything works
perfect
unless I do a portscan on this machine. Then OpenVPN simply segfaults. 
I'm using
nmap -T Aggressive <ipaddress> -p 1194


Mon Oct 31 17:08:03 2005 us=485855 PO_WAIT[0,0] fd=3 rev=0x00000001
rwflags=0x0001 arg=0x00000001 [scalable]
Mon Oct 31 17:08:03 2005 us=485945 MULTI: REAP range 16 -> 32
Mon Oct 31 17:08:03 2005 us=485973 MULTI: multi_create_instance called 
Mon Oct 31 17:08:03 2005 us=486033 PO_INIT maxevents=4
flags=0x00000002
Mon Oct 31 17:08:03 2005 us=486059 Re-using SSL/TLS context
Mon Oct 31 17:08:03 2005 us=486091 MTU DYNAMIC mtu=0, flags=1, 0 ->
140
Mon Oct 31 17:08:03 2005 us=486108 TLS: tls_session_init: entry
Mon Oct 31 17:08:03 2005 us=486221 PID packet_id_init seq_backtrack=0 
time_backtrack=0
Mon Oct 31 17:08:03 2005 us=486364 PID packet_id_init seq_backtrack=0 
time_backtrack=0
Mon Oct 31 17:08:03 2005 us=486398 TLS: tls_session_init: new session 
object, sid=d9b0a377 97bb2ba0
Mon Oct 31 17:08:03 2005 us=486415 TLS: tls_session_init: entry
Mon Oct 31 17:08:03 2005 us=486437 PID packet_id_init seq_backtrack=0 
time_backtrack=0
Mon Oct 31 17:08:03 2005 us=486503 PID packet_id_init seq_backtrack=0 
time_backtrack=0
Mon Oct 31 17:08:03 2005 us=486530 TLS: tls_session_init: new session 
object, sid=e7b0b371 1f6a5f51
Mon Oct 31 17:08:03 2005 us=486558 Control Channel MTU parms [ L:1543 
D:140 EF:40 EB:0 ET:0 EL:0 ]
Mon Oct 31 17:08:03 2005 us=486583 MTU DYNAMIC mtu=1450, flags=2, 1543 
-> 1450
Mon Oct 31 17:08:03 2005 us=486609 Data Channel MTU parms [ L:1543
D:1450 EF:43 EB:4 ET:0 EL:0 ]
Mon Oct 31 17:08:03 2005 us=486688 Local Options String: 'V4,dev-type 
tun,link-mtu 1543,tun-mtu 1500,proto TCPv4_SERVER,cipher BF-CBC,auth
SHA1,keysize 128,key-method 2,tls-server'
Mon Oct 31 17:08:03 2005 us=486712 Expected Remote Options String:
'V4,dev-type tun,link-mtu 1543,tun-mtu 1500,proto TCPv4_CLIENT,cipher 
BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Mon Oct 31 17:08:03 2005 us=486775 Local Options hash (VER=V4):
'7e068940'
Mon Oct 31 17:08:03 2005 us=486809 Expected Remote Options hash
(VER=V4): 'db02a8f8'
Mon Oct 31 17:08:03 2005 us=486832 STREAM: RESET
Mon Oct 31 17:08:03 2005 us=486848 STREAM: INIT maxlen=1543
Mon Oct 31 17:08:03 2005 us=486932 TCP: accept(3) failed: Software
caused connection abort (errno=130)
Mon Oct 31 17:08:03 2005 us=486962 PID packet_id_free
Mon Oct 31 17:08:03 2005 us=487030 PID packet_id_free
Mon Oct 31 17:08:03 2005 us=487048 PID packet_id_free
Mon Oct 31 17:08:03 2005 us=487063 PID packet_id_free
Mon Oct 31 17:08:03 2005 us=487115 PID packet_id_free
Mon Oct 31 17:08:03 2005 us=487130 PID packet_id_free
Mon Oct 31 17:08:03 2005 us=487146 PID packet_id_free
Mon Oct 31 17:08:03 2005 us=487159 PID packet_id_free
Mon Oct 31 17:08:03 2005 us=487179 PID packet_id_free
Mon Oct 31 17:08:03 2005 us=487206 MULTI: multi_close_instance called 


If you need further information or need someone to test code -> Drop
me
a line. I would love to see this bug fixed, because it's actually a
pretty easy DOS and prohibits the use of OpenVPN on a production
machine.


Many thanks
Marc





-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information 
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


One question:

This happens if you are using the tls-auth directive?

As far as i know, if you use the tls auth, the packet that the nmap
tool
generate, will be dropped, as it doesn't have the right hmac code. I
think that using tls-auth can be a temporary workaround until that bug 
is fixed.



This didn't help a bit.
Anyway thanks for your fast reply.
Any other ideas?


I've tested this on Linux (2.6.5), and it appears that the linux
network stack doesn't allow the nmap packets through to OpenVPN, at least 
using your particular nmap command line.
However I then ran a test where I forced the TCP accept call to fail, and 
I was able to reproduce the segfault.  I'm working on a fix now, and
should have a patch within a few hours.


Hi,
I guess a stack trace could be helpful. At least to verify that we're talking about the same bug. 

Thanks
Marc


#0  setenv_trusted (es=0xc8ccc, info=0x0) at socket.c:1288
#1 0x0003320c in multi_client_disconnect_setenv (m=0xffbfebb0, mi=0xc0538) 
    at forward-inline.h:219
#2 0x0003326c in multi_client_disconnect_script (m=0xffbfebb0, mi=0xc0538) 
    at multi.c:410
#3 0x00033434 in multi_close_instance (m=0xffbfebb0, mi=0xc0538, shutdown=0) 
    at multi.c:479

Reply via email to