On Tue, 1 Nov 2005, [ISO-8859-1] Marc Brünink wrote: > > 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
This issue (i.e. the OpenVPN server segfaulting if the accept() call returns an error status) is now fixed in 2.0.4. James
