If you read my article back in February Using Cisco? STOP what you’re doing and read this! (CDP Vulnerabilities in 2020!) you’d find that Cisco has been having a banner year when it comes to exploits in IOS XR code! Between “CVE-2020-3118 – IOS XR remote code execution” and “CVE-2020-3120 – Denial of service of FXOS, IOS XR, and NX-OS devices”, and who knows how many other CVEs, vulnerabilities and exploits to come out this year, now we have CVE-2020-3566 Cisco IOS XR Software DVMRP Memory Exhaustion Vulnerability.
What’s worse? This has been being ACTIVELY Exploited, known as recently as this past Saturday, 29 August 2020. Cisco warns of actively exploited IOS XR zero-day so this should be taken as seriously as the CDP Vulnerabilities from earlier this year. (hint: If you haven’t patched XR at all this year, it’s definitely time to revisit that immediately)
Wait, but what if I can’t patch?!
You raise a valid point. The reason it is valid is because as of 2:51PM PST 31 August 2020… there is NO released fix for this CVE yet. Cisco says it is a few days away, so it’s important to start planning for this patch (and any other patches like the CDP patches if still left unpatched)
Is there anything you can do about it? Well, no. They list no official “mitigation” strategy. But here are some snippets from the official Cisco Security Advisory cisco-sa-iosxr-dvmrp-memexh-dSmpdvfz so you can start to investigate and take action where and when appropriate.
Vulnerable Products
This vulnerability affects any Cisco device that is running any release of Cisco IOS XR Software if an active interface is configured under multicast routing.
Determine Whether Multicast Routing Is Enabled
An administrator can determine whether multicast routing is enabled on a device by issuing the show igmp interface command. The following output shows a device with multicast routing enabled:
RP/0/0/CPU0:router# show igmp interface
Loopback0 is up, line protocol is up
Internet address is 10.144.144.144/32
IGMP is enabled on interface
Current IGMP version is 3
IGMP query interval is 60 seconds
IGMP querier timeout is 125 seconds
IGMP max query response time is 10 seconds
Last member query response interval is 1 seconds
IGMP activity: 3 joins, 0 leaves
IGMP querying router is 10.144.144.144 (this system)
TenGigE0/4/0/0 is up, line protocol is up
Internet address is 10.114.8.44/24
IGMP is enabled on interface
Current IGMP version is 3
IGMP query interval is 60 seconds
IGMP querier timeout is 125 seconds
IGMP max query response time is 10 seconds
Last member query response interval is 1 seconds
IGMP activity: 9 joins, 4 leaves
IGMP querying router is 10.114.8.11
If the output of show igmp interface is empty, multicast routing is not enabled and the device is not affected by this vulnerability.
Determine Whether the Device Is Receiving DVMRP Traffic
An administrator can determine whether the device is receiving DVMRP traffic by issuing the show igmp traffic command. The following output shows a device that is receiving DVMRP traffic:
RP/0/0/CPU0:router#show igmp traffic
Fri Feb 13 12:00:00.000 UTC
IGMP Traffic Counters
Elapsed time since counters cleared: 01:09:27
Received Sent
Valid IGMP Packets 380220 301
Queries 0 143
Reports 0 158
Leaves 0 0
Mtrace packets 0 0
DVMRP packets 380220 0
If the DVMRP packets entry contains values of zero in both columns, and the counters remain zero on subsequent execution of the command, the device is not receiving DVMRP traffic.
So no IGMP and DVMRP can be a good sign!
If you are vulnerable though, your device could start to experience memory exhaustion. (I’ve run into that from an old http/https java vulnerability in the regular IOS Cisco Routers way back, and it was horrible to recover from!) So while “process restart igmp” is said to be able to recover some memory, I wouldn’t entirely bet on it as exhausted memory can be ghosted and zombied out and you’re in for a losing battle over time.
There are some Indicators of Compromise (IOC)s for this, so you can start having your SIEMs, loggers and other things keep an eye out, or setup a rule to monitor for this explicitly
Indicators of Compromise
When a device is experiencing memory exhaustion based on exploitation of this vulnerability, the following messages may be seen in the system logs:
RP/0/RSP1/CPU0:Aug 28 03:46:10.375 UTC: raw_ip[399]: %PKT_INFRA-PQMON-6-QUEUE_DROP : Taildrop on XIPC queue 1 owned by igmp (jid=1175)
RP/0/RSP0/CPU0:Aug 28 03:46:10.380 UTC: raw_ip[399]: %PKT_INFRA-PQMON-6-QUEUE_DROP : Taildrop on XIPC queue 1 owned by igmp (jid=1175)
RP/0/RSP0/CPU0:Aug 28 03:49:22.850 UTC: dumper[61]: %OS-DUMPER-7-DUMP_REQUEST : Dump request for process pkg/bin/igmp
RP/0/RSP0/CPU0:Aug 28 03:49:22.851 UTC: dumper[61]: %OS-DUMPER-7-DUMP_ATTRIBUTE : Dump request with attribute 7 for process pkg/bin/igmp
RP/0/RSP0/CPU0:Aug 28 03:49:22.851 UTC: dumper[61]: %OS-DUMPER-4-SIGSEGV : Thread 9 received SIGSEGV – Segmentation Fault
There are some “Workarounds” of Mitigation (sort of) but be wary of these as it can have drastic consequences if you’re legitimately using IGMP and DVMRP as part of your operational workloads. I’m including them here with a strict disclaimer of “BE CAREFUL!”
Workarounds
Although there are no workarounds for this vulnerability, there are multiple mitigations available to customers depending on their needs.
As a first line of defense, it is recommended that customers implement a rate limiter. This will require that customers understand their current rate of IGMP traffic and set a rate lower than the current average rate. In configuration mode, the customer can enter the lpts pifib hardware police flow igmp rate command as follows:
RP/0/0/CPU0:router(config)# lpts pifib hardware police flow igmp rate <value>
This command will not remove the exploit vector. However, the command will reduce the traffic rate and increase the time necessary for successful exploitation. The customer can use this time to perform recovery actions.
As a second line of defense, a customer may implement an access control entry (ACE) to an existing interface access control list (ACL). Alternatively, the customer can create a new ACL for a specific interface that denies DVMRP traffic inbound on that interface. The following example creates an ACL and denies DVMRP traffic:
RP/0/0/CPU0:router(config)# ipv4 access-list <acl_name> deny igmp any any dvmrp
It is recommended to disable IGMP routing for an interface where IGMP processing is not needed. In IGMP router configuration mode, the customer can enter the router disable command as follows:
RP/0/0/CPU0:router(config)# router igmp
RP/0/0/CPU0:router(config-igmp)# interface <interface_name>
RP/0/0/CPU0:router(config-igmp-name-if)# router disable
So I will leave you with, Be careful, be wary, CHECK if you’re affected by this vulnerability, also check if you patched the CDP Vulnerability from earlier this year! A good gauge is… if you haven’t patched this year, chances are … You haven’t patched a bunch of things!
Either way, stay safe and keep your Infrastructure safe!