[strongSwan-dev] Is strongswan is affected by CVE-2016-5361

[Nirmoy Das]

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