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 _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
