[PATCH 1/1] Security: Reduce impact of bogus key setup packet DoS
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
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
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
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.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the sgo-software-discuss