Thanks Tobias for the detailed explanation :)
On 06/20/2016 11:30 AM, Tobias Brunner wrote: > Hi Nirmoy, > >> Is by any chance strongswan is affected by this recent reported >> security bug, CVE-2016-5361 ? > > Yes, if IKEv1 in Aggressive Mode (AM) is used. This is due to an > inherent deficiency of the protocol. When using AM the client sends a > request, the server responds and then there is a third message from the > client that is not acknowledged by the server. So the client has no > direct way of knowing whether the server actually received that message. > One option, which strongSwan implements, is for the server to > retransmit the response while it hasn't received the third message yet. > Unfortunately, this means that sending an unverified AM request with an > arbitrary source IP may trigger multiple, several hundred bytes large, > responses that are sent to that IP. The size of the response will > depend on the DH group and authentication method (e.g. if certificates > are used). > > strongSwan as responder to an AM request will retransmit its response > according to its configurable retransmission timings [1]. However, > because the IKE_SA is only half-open, it will get deleted after a > configurable timeout (default is 30s). So with the default settings the > original response and three retransmits are sent over the course of 30 > seconds. Additionally, the built-in DoS protection prevents that too > many half-open connections with the same source IP are created (the > default is 5, but depending on the timing there could be a few more as > half-open SAs are currently only counted after handling the initial > request). Which means that the number of messages that could get sent > to an arbitrary IP within every 30 seconds is limited. > > Anyway, since only IKEv1 in Aggressive Mode is affected, using Main Mode > or, preferably, IKEv2 completely avoids any potential exposure to this > issue. It would also be trivial to disable sending the retransmits > ([2]), however, that breaks the connection if the third message is lost. > But again, only IKEv1 AM connections are affected. > > Instead of sending retransmits unconditionally and if AM is not combined > with XAuth (which it often is) the server could probably use Transaction > (for Mode Config) or Quick Mode requests from the client to trigger a > retransmit of the second AM message (to get the client to resend the > third message, if it is able to do so). But with XAuth (or Mode Config > in push mode) that's not possible as the next message has to be sent by > the server. However, in this case the client could theoretically use > the absence of a Transaction request for some time as trigger to resend > the third AM message. > > strongSwan does neither of these things and, as mentioned, simply > retransmits the AM response and, as client, does not retransmit the > third message unless it receives a retransmit of the second. And if AM > is directly followed by Quick Mode or Mode Config in pull mode it > couldn't even retransmit the third AM message as that new request > replaces it - but as mentioned AM is often combined with XAuth. > > The best way to prevent this issue is to use IKEv2. If IKEv1 has still > to be used for some legacy reasons it should be restricted to Main Mode. > > Regards, > Tobias > > [1] https://wiki.strongswan.org/projects/strongswan/wiki/Retransmission > [2] https://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=4e16732c > Regards, Nirmoy -- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Maxfeldstr. 5 D-90409 Nürnberg / Phone: +49-911-740 18-4 _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
