cisco-sa-pak-mem-exhst-3ke9FeFy · High · Published · Updated
A vulnerability in the multicast traceroute version 2 (Mtrace2) feature of Cisco IOS XR Software could allow an unauthenticated, remote attacker to exhaust the UDP packet memory of an affected device. This vulnerability exists because the Mtrace2 code does not properly handle packet memory. An attacker could exploit this vulnerability by sending crafted packets to an affected device. A successful exploit could allow the attacker to exhaust the incoming UDP packet memory. The affected device would not be able to process higher-level UDP-based protocols packets, possibly causing a denial of service (DoS) condition. Note: This vulnerability can be exploited using IPv4 or IPv6. Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability. This advisory is available at the following link:https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-pak-mem-exhst-3ke9FeFy This advisory is part of the September 2024 release of the Cisco IOS XR Software Security Advisory Bundled Publication. For a complete list of the advisories and links to them, see Cisco Event Response: September 2024 Semiannual Cisco IOS XR Software Security Advisory Bundled Publication.
Use an Infrastructure Access Control List (iACLs) to Block Port 33433
To protect infrastructure devices and minimize the risk, impact, and effectiveness of direct infrastructure attacks, administrators are advised to deploy iACLs to enforce policies on traffic that is sent to infrastructure equipment. Administrators can construct an iACL by explicitly permitting only authorized traffic that is sent to infrastructure devices in accordance with existing security policies and configurations. For the maximum protection of infrastructure devices, deployed iACLs should be applied in the ingress direction on all interfaces to which an IP address has been configured. An iACL mitigation cannot completely protect against this vulnerability when the attack originates from a trusted source address.
The iACL policy denies unauthorized Mtrace2 communications packets that are sent to UDP port 33433 on affected devices. In the following example, 192.168.60.0/24 is the IP address space that is used by the affected devices. Care should be taken to allow required traffic for routing and administrative access before denying all unauthorized traffic. Whenever possible, infrastructure address space should be distinct from the address space for user and services segments. Using this addressing methodology will assist with the construction and deployment of iACLs.
Note: Mtrace2 also supports IPv6, so a corresponding IPv6 iACL is required if the device has IPv6 configured.
Note: Cisco uses UDP port 33433, not 33435, for Mtrace2.
ipv4 access-list Infrastructure-ACL-Policy
!
!-- The following vulnerability-specific access control entries
!-- (ACEs) can drop Mtrace version 2 communication packets
! deny udp any 192.168.60.0 0.0.0.255 eq 33433
!
!-- Explicit deny ACE for traffic sent to addresses configured
!-- within the infrastructure address space
! deny ip any 192.168.60.0 0.0.0.255
!
!-- Permit or deny all other Layer 3 and Layer 4 traffic in
!-- accordance with existing security policies and configurations
!
!-- Apply iACL to interfaces in the ingress direction
!
interface GigabitEthernet0/0 ipv4 access-group Infrastructure-ACL-Policy in
Restarting the Internet Group Management Protocol (IGMP) process or the Multicast Listener Discovery (MLD) process, or both processes, before the device runs out of memory can ensure that other processes will not be affected. (See the Details section for more information.) Restarting these processes does not prevent the device from leaking UDP memory.
Use the process restart mld or process restart igmp command to restart the respective processes.
While these mitigations have been deployed and were proven successful in a test environment, customers should determine the applicability and effectiveness in their own environment and under their own use conditions. Customers should be aware that any workaround or mitigation that is implemented may negatively impact the functionality or performance of their network based on intrinsic customer deployment scenarios and limitations. Customers should not deploy any workarounds or mitigations before first evaluating the applicability to their own environment and any impact to such environment.