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

[Tobias Brunner]

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