Bug 1348

Summary: SSLIOP is wide open for simple denial of service attack
Product: TAO Reporter: Knut-Håvard Aksnes <knut>
Component: SSLIOP Pluggable ProtocolAssignee: Ossama Othman <ossama.othman>
Status: RESOLVED FIXED    
Severity: major CC: david
Priority: P3    
Version: 1.2.5   
Hardware: x86   
OS: Windows NT   
Bug Depends on:    
Bug Blocks: 1277    

Description Knut-Håvard Aksnes 2002-11-01 04:08:15 CST
The TAO SSLIOP implementation is open to a fairly simple denial of service
attack. Just telnet the ssliop port used by the server then do nothing. The
server will be blocked for other users. We are using -SSLAuthenticate SERVER
Comment 1 Ossama Othman 2002-11-01 09:36:38 CST
Thanks alot for pointing that out!

I suppose that a quick fix would be to override the accept_svc_handler() method
of the connection accept strategy employed by TAO's SSLIOP implementation so 
that it actually passes a real timeout value to the underlying passive 
connection code.  That way, we could at least bound the time the DoS attack 
lasts.  Does that sound reasonable?  If you know of a better solution, please 
let me know.
Comment 2 Ossama Othman 2002-11-01 09:43:48 CST
BTW, we could probably employ a similar timeout defense strategy for TAO's 
other pluggable protocols, including plain IIOP.
Comment 3 Ossama Othman 2002-11-01 09:58:46 CST
Nevermind, the last comment.  IIOP doesn't suffer from the multiple handshake 
DoS vulnerability currently found in TAO's SSLIOP implementation.
Comment 4 Ossama Othman 2002-11-01 10:06:09 CST
Making this block TAO 1.3.
Comment 5 Knut-Håvard Aksnes 2002-11-02 09:23:40 CST
A full fix must:
	a) Avoid using reads or writes where blocking is a possibility  (A
           reactor based mechanism can be used)
	b) Timeout passive connections to avoid somebody holding all file
           descriptors using passive connections. 
Comment 6 Ossama Othman 2002-11-03 16:23:32 CST
The approach I suggested would take care of both conditions since passing the
timeout value to the underlying ACE_SSL_SOCK_Acceptor::accept() method would
cause the ACE_SSL_SOCK_Acceptor to place the SSL stream handle in non-blocking
mode.  Otherwise, there would be no way to timeout the reads/writes.

Comment 7 Ossama Othman 2002-11-12 15:06:34 CST
FYI, I have a fix for this problem sitting in my local workspace.  I'll commit
it once the CVS repository is back up later today.
Comment 8 Ossama Othman 2002-11-13 16:20:37 CST
Fixed:

Wed Nov 13 14:15:33 2002  Ossama Othman  <ossama@uci.edu>

	* orbsvcs/orbsvcs/SSLIOP/SSLIOP_Accept_Strategy.h:
	* orbsvcs/orbsvcs/SSLIOP/SSLIOP_Accept_Strategy.cpp:

	  New TAO_SSLIOP-specific TAO_Accept_Strategy implementation.
	  This accept strategy builds on on the TAO_Accept_Strategy
	  implementation.  It sub-classes that class, and overrides the
	  accept_svc_handler() method so that a timeout value may be
	  passed to the underlying peer acceptor.  This is necessary to
	  defend against a simple Denial-of-Service attack.  See the
	  comments in the header for details.  [Bug 1348]

	* orbsvcs/orbsvcs/SSLIOP/SSLIOP_Factory.cpp (init):

	  Added new "-SSLAcceptTimeout" option.  This option allows
	  applications to override the default 10 second TAO_SSLIOP
	  accept() timeout.

	  (make_acceptor):

	  Pass the timeout value to the SSLIOP_Acceptor's constructor.

	* orbsvcs/orbsvcs/SSLIOP/SSLIOP_Acceptor.h:

	  Updated use the new TAO_SSLIOP_Accept_Strategy implementation
	  instead of the generic one supplied by TAO.  [Bug 1348]

	  Cache the accept timeout value in a member variable.

	* orbsvcs/orbsvcs/SSLIOP/SSLIOP_Acceptor.cpp
	  (TAO_SSLIOP_Acceptor):

	  Initialize the accept timeout member from the value passed to
	  this constructor from the SSLIOP_Factory.

	  (ssliop_open_i):

	  Pass the accept timeout value to the
	  TAO_SSLIOP_Accept_Strategy's constructor.  [Bug 1348]