Facebook Google Plus Twitter LinkedIn YouTube RSS Menu Search Resource - BlogResource - WebinarResource - ReportResource - Eventicons_066 icons_067icons_068icons_069icons_070

[R1] Cisco Multiple Routers Fragmented IKEv2 Packet Handling Remote Integer Overflow

High

Synopsis

While developing a plugin to test Cisco ASA devices, it was discovered that additional Cisco routers configured with IKEv2 are vulnerable to the remote overflow (CVE-2016-1287) as well. The Cisco advisory covering the vulnerability in the ASA does not mention any non-security devices as being impacted. Based on our testing, several 'regular' routers are vulnerable which suggests this may be a systemic problem in the IOS codebase, and may affect any Cisco device that supports IKEv2 (and possibly IKEv1) functionality.

By creating a Cisco fragmentation payload (ID 132) that is less than 7 bytes, a remote attacker can crash the router. After further investigation it appears that the Cisco router being tested is also affected by the integer underflow bug described in Exodus Intel's "Execute My Packet" advisory. In the ikev2_add_rcv_frag() function, the length of the received fragment is not checked at the beginning of the function, as it is in a patched ASA device.

After some checking on fragment ID and fragment number to make sure they are proper, the length of the received fragment is added to the length of an IKEv2 message to be assembled, and the fragment is added to the fragment list to be assembled when the last fragment is received. In the ikev2_get_assembled_pkt() function, when the last fragment is received, the function starts to assemble the fragments stored by ikev2_add_rcv_frag(). It pulls up all the fragmentation payloads (complete payload format with header), calculates the size of the data carried in each fragmentation payload by subtracting 8 (size of fragmentation payload header) from the fragment length, and copies the fragment data to an assembly buffer.

This appears to be the same or very similar issue described in Exodus Intel's advisory, and that Cisco didn't seem to patch their routers supporting its own fragmentation protocol (payload ID 132).

Based on testing, and the devices Tenable has access to, we believe this will likely impact any Cisco IOS device that supports IKEv2 (and possibly IKEv1) with fragmentation enabled. While a remote denial of service was confirmed, Tenable did not do further testing for remote code execution potential, but we cannot rule that out.

Solution

Cisco has released an advisory and provided a solution for IOS-based devices impacted by this issue, tracked as CSCux38417. Tenable has authored two Nessus plugins to detect this issue (one for IOS, one for IOS XE).

Disclosure Timeline

2016-02-25 - Issue Discovered
2016-02-26 - Continued testing of more router models
2016-02-26 - Submitted to ZDI for consideration, case bmartin0009
2016-03-22 - ZDI declines, as they do not have the hardware to validate
2016-03-22 - Reported to Cisco PSIRT
2016-03-22 - Cisco asks for IOS versions. Tenable sends, since original mail forgot.
2016-03-23 - Cisco replies with extensive detail including fixed versions, as they had already discovered this internally as well. PSIRT-1765821591 assigned
2016-03-23 - Cisco publishes advisory

All information within TRA advisories is provided “as is”, without warranty of any kind, including the implied warranties of merchantability and fitness for a particular purpose, and with no guarantee of completeness, accuracy, or timeliness. Individuals and organizations are responsible for assessing the impact of any actual or potential security vulnerability.

Tenable takes product security very seriously. If you believe you have found a vulnerability in one of our products, we ask that you please work with us to quickly resolve it in order to protect customers. Tenable believes in responding quickly to such reports, maintaining communication with researchers, and providing a solution in short order.

For more details on submitting vulnerability information, please see our Vulnerability Reporting Guidelines page.

If you have questions or corrections about this advisory, please email [email protected]