Project

General

Profile

Bug #2536

Issues while handling faulty CREATE_CHILD_SA messages

Added by Jacek Kościow over 1 year ago. Updated over 1 year ago.

Status:
Closed
Priority:
Normal
Category:
libcharon
Target version:
Start date:
Due date:
Estimated time:
Affected version:
5.5.3
Resolution:
Fixed

Description

There is a problem with handling unexpected/faulty INVALID_KE_PALOAD messages in Strongswan.
In the consequence Strongswan is stuck in CREATE_CHILD_SA loop and it blocks other tasks.

Note that these problems have been found due existing fault/misbehavior in the peer node (a Cisco SEG). So this is about vulnerability to such fault/misbehavior.

1st case:

Configuration:
Strongswan uses DH groups 19 (256-bit random ECP group), 14 (2048-bit MODP Group) for IKE and Child (PFS enabled)
Peer uses DH group 14 for IKE and Child (PFS enabled)

- SAs are established using DH group 14
- Strongswan triggers Child SA rekey with KE payload 19, both DH 19 and 14 in proposal payload
- Peer sends INVALID_KE_PAYLOAD with Notification DATA: 0013 (DH 19, instead proper supported DH 14)
- Strongswan triggers Child SA rekey with DH 19
- Peer sends INVALID_KE_PAYLOAD with Notification DATA: 0013 (DH 19, instead proper supported DH 14)
- Strongswan triggers Child SA rekey with DH 19
- and so on…

Strongswan is blocked on handling CREATE_CHILD_SA task (until DELETE message is received from peer).

2nd case:

Configuration:
Strongswan uses DH group 20 for IKE, PFS is not enabled
Peer uses DH group 20 for IKE and Child (PFS enabled)

- SAs are established using DH group 20
- Strongswan triggers Child SA rekey without KE payload (and no DH in proposal payload)
- Peer sends INVALID_KE_PAYLOAD with Notification DATA: 0014 (instead of NO_PROPOSAL_CHOSEN)
- Strongswan triggers Child SA rekey with DH 20 in KE payload (despite PFS was disabled) - however no DH group in proposal payload
- Peer sends INVALID_KE_PAYLOAD with Notification DATA: 0014 (instead of NO_PROPOSAL_CHOSEN)
- Strongswan triggers Child SA rekey with DH 20 in KE payload (despite PFS was disabled) - however no DH group in proposal payload
- and so on…

Strongswan is blocked on handling CREATE_CHILD_SA task (until DELETE message is received from peer).

This 2nd case also does not comply with RFC 7296:

1.3. The CREATE_CHILD_SA Exchange

If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of
the SA offers MUST include the Diffie-Hellman group of the KEi.

strongswan logs.txt (190 KB) strongswan logs.txt Jacek Kościow, 19.02.2018 14:18
invalid_syntax.log (139 KB) invalid_syntax.log Jacek Kościow, 20.02.2018 12:43
ike_invalid_syntax.pcap (4.86 KB) ike_invalid_syntax.pcap Jacek Kościow, 20.02.2018 12:43

Associated revisions

Revision 479af1ed
Added by Tobias Brunner over 1 year ago

Merge branch 'incorrect-inval-ke'

This improves the behavior during CREATE_CHILD_SA exchanges if the peer
sends an INVALID_KE_PAYLOAD with a DH group we didn't request or continues
to return the same notify even if we use the requested group.

Fixes #2536.

History

#1 Updated by Tobias Brunner over 1 year ago

  • Tracker changed from Issue to Bug
  • Subject changed from Possible vulnerability while handling faulty CREATE_CHILD_SA messages to Issues while handling faulty CREATE_CHILD_SA messages
  • Status changed from New to Feedback
  • Target version set to 5.6.2

Note that these problems have been found due existing fault/misbehavior in the peer node (a Cisco SEG)

You noticed this with actual Cisco devices? Do you have more information on the affected IOS versions?

Strongswan is blocked on handling CREATE_CHILD_SA task (until DELETE message is received from peer).

I guess we could abort the rekeying if we already retried with a requested DH group (we do something similar during IKE_SA_INIT) but we are communicating with an authenticated peer here, not an attacker. So I don't really see a vulnerability. And there maybe not that much to gain this way (besides allowing other tasks to run). If the rekeying can't be completed the old CHILD_SA is kept and another rekeying is scheduled (which will probably fail again). Eventually the SA will expire and there will be an attempt to recreate it, but that might again fail (unless this implementation properly handles DH groups during regular CREATE_CHILD_SA exchanges).

- SAs are established using DH group 20
- Strongswan triggers Child SA rekey without KE payload (and no DH in proposal payload)
- Peer sends INVALID_KE_PAYLOAD with Notification DATA: 0014 (instead of NO_PROPOSAL_CHOSEN)
- Strongswan triggers Child SA rekey with DH 20 in KE payload (despite PFS was disabled) - however no DH group in proposal payload
- Peer sends INVALID_KE_PAYLOAD with Notification DATA: 0014 (instead of NO_PROPOSAL_CHOSEN)
- Strongswan triggers Child SA rekey with DH 20 in KE payload (despite PFS was disabled) - however no DH group in proposal payload
- and so on…

Strongswan is blocked on handling CREATE_CHILD_SA task (until DELETE message is received from peer).

Interesting, I guess we should add a check for the requested group and abort the rekeying (or CHILD_SA creation) if a group was requested we don't propose (the initiator currently doesn't check). But again, the peer is authenticated so I don't really see a vulnerability.

This 2nd case also does not comply with RFC 7296:

Yeah, but since this is a reaction to a non-compliant behavior it's probably not that much of a problem.

I pushed fixes for the two issues to the 2536-inval-ke-rekey branch. Let me know if these work for you.

#2 Updated by Jacek Kościow over 1 year ago

You noticed this with actual Cisco devices? Do you have more information on the affected IOS versions?

Yes, ASR1000 with software version 16.5.1b

I pushed fixes for the two issues to the 2536-inval-ke-rekey branch. Let me know if these work for you.

I haven't checked it yet. I'll do it and let you know.

#3 Updated by Tobias Brunner over 1 year ago

  • Target version changed from 5.6.2 to 5.6.3

#4 Updated by Jacek Kościow over 1 year ago

I pushed fixes for the two issues to the 2536-inval-ke-rekey branch. Let me know if these work for you.

After applying this patch we do not accept proposed D-H group (which is expected behavior), but Strongswan treats this situation as fatal error and flushes the tunnel, which results in abrupt termination (without even sending DELETE message). This causes traffic disruption for a few seconds until we are able to reestablish the tunnel. Is it possible to gracefully delete SA so we can immidiatelly reestablish connection?

#5 Updated by Tobias Brunner over 1 year ago

I pushed fixes for the two issues to the 2536-inval-ke-rekey branch. Let me know if these work for you.

After applying this patch we do not accept proposed D-H group (which is expected behavior), but Strongswan treats this situation as fatal error and flushes the tunnel, which results in abrupt termination (without even sending DELETE message). This causes traffic disruption for a few seconds until we are able to reestablish the tunnel. Is it possible to gracefully delete SA so we can immidiatelly reestablish connection?

Which scenario are you testing exactly? Could you provide a log?

#6 Updated by Jacek Kościow over 1 year ago

Tobias Brunner wrote:

I pushed fixes for the two issues to the 2536-inval-ke-rekey branch. Let me know if these work for you.

After applying this patch we do not accept proposed D-H group (which is expected behavior), but Strongswan treats this situation as fatal error and flushes the tunnel, which results in abrupt termination (without even sending DELETE message). This causes traffic disruption for a few seconds until we are able to reestablish the tunnel. Is it possible to gracefully delete SA so we can immidiatelly reestablish connection?

Which scenario are you testing exactly? Could you provide a log?

We are testing scenario in which our node has PFS disabled and Cisco (peer) has it enabled. We are triggering child rekeying, sending proposals without D-H, Cisco does not agree and sends us INVALID_KE_PAYLOAD with its own proposal. We should not accept it as we do not want to use PFS. After applying your patch we indeed did not accept this, but as it’s treated as failure we are flushing away the tunnel without notifying peer.

Please find logs attached

#7 Updated by Tobias Brunner over 1 year ago

We are testing scenario in which our node has PFS disabled and Cisco (peer) has it enabled. We are triggering child rekeying, sending proposals without D-H, Cisco does not agree and sends us INVALID_KE_PAYLOAD with its own proposal. We should not accept it as we do not want to use PFS. After applying your patch we indeed did not accept this, but as it’s treated as failure we are flushing away the tunnel without notifying peer.

Please find logs attached

Thanks. I see, there is a hard failure that we could probably change. I pushed a patch to the branch (also rebased it to the current master). This way the old SA will be kept until it expires (rekeyings are retried until then) and once that happens it will get reestablished (if you use trap policies this could result in multiple SAs, though, because it is first deleted then recreated, so there is a short time without installed SA, where acquires could trigger another instance).

#8 Updated by Jacek Kościow over 1 year ago

Tobias Brunner wrote:

We are testing scenario in which our node has PFS disabled and Cisco (peer) has it enabled. We are triggering child rekeying, sending proposals without D-H, Cisco does not agree and sends us INVALID_KE_PAYLOAD with its own proposal. We should not accept it as we do not want to use PFS. After applying your patch we indeed did not accept this, but as it’s treated as failure we are flushing away the tunnel without notifying peer.

Please find logs attached

Thanks. I see, there is a hard failure that we could probably change. I pushed a patch to the branch (also rebased it to the current master). This way the old SA will be kept until it expires (rekeyings are retried until then) and once that happens it will get reestablished (if you use trap policies this could result in multiple SAs, though, because it is first deleted then recreated, so there is a short time without installed SA, where acquires could trigger another instance).

After receiving INVALID_KE_PAYLOAD (when we have PFS disabled) we are starting to generate new CREATE_CHILD response, without ever finishing it. Somehow this unfinished response is sent to peer, which responds to us with INVALID_SYNTAX. This is the only problem we encountered. Rekeying is properly rescheduled and after our hard expiry timer kicks in tunnel is gracefully deleted and reestablished.

Please find logs and pcap attached

#9 Updated by Tobias Brunner over 1 year ago

Jacek Kościow wrote:

Tobias Brunner wrote:

We are testing scenario in which our node has PFS disabled and Cisco (peer) has it enabled. We are triggering child rekeying, sending proposals without D-H, Cisco does not agree and sends us INVALID_KE_PAYLOAD with its own proposal. We should not accept it as we do not want to use PFS. After applying your patch we indeed did not accept this, but as it’s treated as failure we are flushing away the tunnel without notifying peer.

Please find logs attached

Thanks. I see, there is a hard failure that we could probably change. I pushed a patch to the branch (also rebased it to the current master). This way the old SA will be kept until it expires (rekeyings are retried until then) and once that happens it will get reestablished (if you use trap policies this could result in multiple SAs, though, because it is first deleted then recreated, so there is a short time without installed SA, where acquires could trigger another instance).

After receiving INVALID_KE_PAYLOAD (when we have PFS disabled) we are starting to generate new CREATE_CHILD response, without ever finishing it. Somehow this unfinished response is sent to peer, which responds to us with INVALID_SYNTAX.

Ah, yes. Because the build() call now succeeds, the CREATE_CHILD_SA request is sent, even though no payloads are added to it. We should change the exchange type to avoid that. I fixed the patch.

#10 Updated by Jacek Kościow over 1 year ago

Tobias Brunner wrote:

Ah, yes. Because the build() call now succeeds, the CREATE_CHILD_SA request is sent, even though no payloads are added to it. We should change the exchange type to avoid that. I fixed the patch.

Now it works fine.

#11 Updated by Tobias Brunner over 1 year ago

  • Category set to libcharon
  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to Fixed

Now it works fine.

OK, great. I merged the branch to master.

Also available in: Atom PDF