Multiple Platform remote CPU load issue in Samba 1.x and 2.x

[J. Robert von Behren]

"Christopher R. Hertel" wrote:
> 
> > No.  These requests are all coming in on the same tcp connection (hence
> > they are talking to the same smbd process).
> 
> 'Fraid not.
> 
> You can have multiple TCP connections over the same TCP port.  When a new
> connection comes in, smbd forks a process to handle it.  I just tested
> this using the exploit we're discussing.  You can see the child process
> get spawned, the CPU utilization go up, and then the process go away
> after I kill the attack.

I think there is a bit of confusion on this point.  nc/netcat will
create _exactly one_ tcp connection to the specified port, and then dump
stuff at it.  Hence, in the ps output you showed below, there were only
two smbd processes - the listener, and the one processing the bogus
commands.  Recognizing and handling bogus commands requires user-level
parsing of incoming data, and hence should be handled by the child smbd
process.  Doing early drop of spurious _connections_ is an entirely
different issue, and should be handled differently.

IMO, all of the solutions that have been posed for handling single
connections with a sequence of bad commands are reasonable. 
Unfortunately, dealing with DOS attacks that create _many_ connections
are much more difficult to thwart.  The only true way to thwart these is
to have the kernel do IP-address filtering (similar to tcpd), and drop
any connections from hosts that are determined to be bad citizens.  If
we have to fork another smbd process before this drop can occur, then we
will have already lost this battle, as an attacker could easily cause us
to spawn an ulimited number of smbd processes (or simply use all
available smbd processes up with bogus connections).  This is a well
known and well studied problem with web servers.  
The resource containers paper from Peter Druschel's research group at
Rice gives a good description of this, and how you can solve it with an
appropriately designed network stack: 
http://www.cs.rice.edu/~gaurav/papers/osdi99.ps.

For our purposes, I think the best we can hope for is to keep track of
IP addresses that are causing problems, and blacklist them for a time. 
A policy like "after N bogus connections from a host, drop new
connections from that host for M minutes" would do the trick.  "bogus
connections" would be defined as connections that had to be killed b/c
of too many bad SMB commands.

Best,

-Rob