[PATCH 1/1] Security: Reduce impact of bogus key setup packet DoS

Richard Kettlewell rjk at terraraq.org.uk
Sun Jul 10 13:38:11 BST 2011


On 07/07/2011 01:00, Ian Jackson wrote:
[...]
> In this patch we fix the latter problem.  It is simply a bug that the
> session key and data transport peer address (resulting from a previous
> successful key exchange) are discarded when a key setup fails.
>
> We also provide a test program "test-example/bogus-setutp-request.c"
> which can be used to reproduce the problem.

I had to modify the test program slightly to get it to work properly 
(diff attached).  The DoS and the enter_wait_state() patch behave as 
described.

Thoughts:

1) There's a comment in the code suggesting maintaining a blacklist of 
bad setup sources.  I'm not really convinced by this suggestion: slow, 
overloaded or poorly connected systems might fail to complete setup for 
an extended period, making them difficult to distinguish from a 
malicious source.

2) The setup state is broken out into a separate chunk in 'struct site'. 
  Assuming that reflects reality (which I've not checked!) it doesn't 
seem like it would be especially onerous to have multiple parallel key 
exchanges selected by source IP address, and to accept whichever 
completed first and junk the rest.

Neither of these help if the attacker has many IP addresses available 
(in both cases there would have to be some kind of size limit to prevent 
resource exhaustion).

3) Often the legitimate setup source for a site will be reasonably easy 
to discover out of band - for instance there may be a DNS name that 
reliably points at it.  secnet could limit what addresses it would 
accept MSG1 from for such sites.  This doesn't introduce a new 
dependency as it already uses DNS to discover the target address (in 
fact it would usually be the same name).

This does not help if the legitimate peer does not have a stable name.

ttfn/rjk
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bsr.diff
URL: <http://www.chiark.greenend.org.uk/pipermail/sgo-software-discuss/attachments/20110710/85559273/attachment.asc>


More information about the sgo-software-discuss mailing list