In order to be vulnerable to CVE-2024-6437, one of the following three conditions must be met:
(1) A PBR policy must be configured with a rule which redirects to a next hop or set of next hops.
switch(config)#show policy-map type pbr\nService policy pmap1\n Configured on: Ethernet20/1\n Applied on: Ethernet20/1\n 10: Single match statement\n Match:\n 0 permit ip any host 10.2.1.1\n Configured actions: set nexthop 10.20.1.1\n Active routing action:\n VRF default\n Route to nexthop 10.20.1.1 default\n 20: Single match statement\n Match:\n 0 permit ip any host 10.3.1.1\n Configured actions: set nexthop 10.20.2.1\n Active routing action:\n VRF default\n Route to nexthop 10.20.2.1 default\n 30: Single match statement\n Match:\n 0 permit ip 10.50.1.0/24 any\n Configured actions: set nexthop 10.20.3.1\n Active routing action:\n VRF default\n Route to nexthop 10.20.3.1 default\n 40: Single match statement\n Match:\n 0 permit ip any any\n Configured actions: set nexthop 10.20.4.1\n Active routing action:\n VRF default\n Route to nexthop 10.20.4.1 default\n
With this configuration, any packet that does not match the PBR match rules will fall through and match the \"default\" match-all rule and should get redirected to the next hop 10.20.4.1.
OR
(2) A BGP Flowspec must be configured with a rule which redirects to a next hop or set of next hops.
switch#show flow-spec ipv4\nFlow specification rules for VRF default\nConfigured on: Ethernet20/1\nApplied on: Ethernet20/1\n Flow-spec rule: 10.100.0.0/16;*;\n Rule identifier: 1\n Matches:\n Destination prefix: 10.100.0.0/16\n Actions:\n Redirect: VRF default\n Route via next hop 10.20.4.1\n Status:\n Installed: yes\n Counter: 0 packets, 0 bytes\n
With this configuration, all traffic ingressing Ethernet20/1 with destination addresses in the 10.100.0.0/16 subnet should get redirected to the next hop 10.20.4.1.
OR
(3) An interface traffic policy must be configured with a rule that redirects to a next hop or set of next hops.
switch#show traffic-policy interface\nTraffic policy foo\n Configured on input of interfaces: Ethernet20/1\n Applied on input of interfaces for IPv4 traffic: Ethernet20/1\n Applied on input of interfaces for IPv6 traffic:\n Applied on input of interfaces for MAC traffic:\n Configured on output of interfaces:\n Applied on output of interfaces for IPv4 traffic:\n Applied on output of interfaces for IPv6 traffic:\n Total number of rules configured: 3\n match rule1 ipv4\n Destination prefix: 10.100.0.0/16\n Actions: Redirect next hop 10.20.4.1\n Active routing action:\n VRF default\n Route via next hop 10.20.4.1 VRF default\n match ipv4-all-default ipv4\n match ipv6-all-default ipv6\n
With this configuration, all traffic ingressing Ethernet20/1 with destination addresses in the 10.100.0.0/16 subnet should get redirected to the next hop 10.20.4.1.
The recommended resolution is to upgrade to a remediated software version that contains the ip software forwarding options action drop CLI command, and configure the command at your earliest convenience. Arista recommends customers move to the latest version of each release that contains all the fixes listed below. For more information about upgrading see EOS User Manual: Upgrades and Downgrades
CVE-2024-6437 has been fixed in the following releases:
For all affected systems, the suggested mitigation for all three affected features is to drop all IPv4 options traffic via the ip software forwarding options action drop, available in 4.32.2F and later releases in the 4.32 train, 4.31.5M and later releases in the 4.31 train, and 4.30.8M and later releases in the 4.30 train. The command installs an iptables rule that drops all IPv4 options traffic in the filter table of the FORWARD chain.
switch(config)#ip software forwarding options action drop\n \n# Below is shown to illustrate what the rule does. This is not a command that needs to be run.\n \nswitch(config)#bash sudo iptables -vnL EOS_FORWARD\nChain EOS_FORWARD (1 references)\n pkts bytes target prot opt in out source destination\n 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 u32 ! \"0x0>>0x18=0x45\"\n 0 0 REJECT all -- * fwd+ 0.0.0.0/0 0.0.0.0/0 u32 ! \"0x0>>0x18=0x45\" reject-with icmp-admin-prohibited\n 0 0 DROP all -- * ma+ 0.0.0.0/0 0.0.0.0/0\n 0 0 ACCEPT all -- * * !127.0.0.0/8 !127.0.0.0/8\nAdditionally, in 7280R3, 7500R3, and 7800R3 systems, the system-rule overriding-action redirect command (present in EOS-4.28.0F and newer releases) can be used to allow for all of the affected features' set nexthop action to take precedence over the system ACL's trap action to CPU. See TCAM redirect action overriding system rules - TOI for more information.