Cisco IOS XR Software Management Interface ACL Bypass Vulnerability

At the time of publication, this vulnerability affected the following Cisco platforms and Cisco IOS XR Software releases if they had an IPv4 or IPv6 ACL attached to the management interface:

Affected Cisco Platform
Affected Cisco IOS XR Software Releases

8000 Series Routers
Software image earlier than the first fixed release

ASR 9000 Series Aggregation Services Routers
Releases 24.1.1 and later but earlier than the first fixed release

IOS XR White box (IOSXRWBD)
Releases 7.9.1 and later but earlier than the first fixed release

IOS XRd vRouters
Software image earlier than the first fixed release

IOS XRv 9000 Routers
Releases 24.1.1 and later but earlier than the first fixed release

Network Convergence Series (NCS) 540 Series Routers\
(NCS540-iosxr base image)
Releases 7.9.1 and later but earlier than the first fixed release

NCS 540 Series Routers\
(NCS540L-iosxr base image)
All releases earlier than the first fixed release

NCS 560 Series Routers
Releases 24.2.1 and later but earlier than the first fixed release

NCS 1010 Platforms
Software image earlier than the first fixed release

NCS 1014 Platforms
Software image earlier than the first fixed release

NCS 5500 Series Routers
Releases 7.9.1 and later but earlier than the first fixed release

NCS 5700 Series Routers
NCS5700 base image earlier than the first fixed release

For more information about which Cisco software releases were vulnerable at the time of publication, see the Fixed Software section of this advisory. See the Details section in the bug ID(s) at the top of this advisory for the most complete and current information.

### Determine Whether a Configuration Is Vulnerable

To determine whether a device from the preceding table has a vulnerable configuration, complete the following steps:

**Step 1: Determine whether there is an IP ACL**

To determine whether the device has an IP ACL on the management interface that is configured to block gRPC, SSH, or NETCONF over SSH, use the **show running-config interface mgtEth ** CLI command. The following example shows the output on a device that has an IPv4 ACL configured on the management interface:

>
>
> “`
> RP/0/RP0/CPU0:Router#**show running-config interface mgmtEth 0/RP0/CPU0/0** \
> Wed Sep 9 16:00:00.000 UTC\
> **interface MgmtEth**0/RP0/CPU0/0\
> ipv4 address 10.10.10.10 255.255.255.0\
> i**pv4 access-group** MGMT_ACL ingress\
> !
>
> RP/0/RP0/CPU0:Router#
>
> “`
>
>

Examine the contents of the MGMT\_ACL. If it is configured to deny the ports that are configured for gRPC, SSH, or NETCONF over SSH, this is a match. Proceed to **Step 2**.

Otherwise, the device is not affected. Stop here.

**Step 2: Determine the status of gRPC**

To determine whether gRPC is configured on a device, use the **show running-config grpc** CLI command. The following example shows the output on a device that has gRPC enabled and configured:

>
>
> “`
> RP/0/RP0/CPU0:Router# **show running-config grpc**\
> Wed Sep 9 16:00:00.000 UTC\
> **grpc**\
> port 57400\
> !\
> \
> RP/0/RP0/CPU0:Router#
> “`
>
>

If gRPC is enabled, use the **show running-config linux networking** CLI command to determine whether Traffic Protection for Linux Networking is configured. The following example shows the output on a device that allows gRPC only from a single remote subnet on a single local interface:

>
>
> “`
> RP/0/RP0/CPU0:Router# **show running-config linux networking**\
> Wed Sep 9 16:00:00.000 UTC\
> linux networking\
> vrf default\
> address-family ipv4\
> protection\
> protocol tcp local-port all default-action deny\
> !\
> protocol tcp local-port 57400 default-action deny\
> permit remote-address 192.0.2.0/24 interface HundredGigE0/0/0/25\
> !\
> !\
> !\
> !\
> RP/0/RP0/CPU0:Router#
> “`
>
>

If gRPC is enabled and Traffic Protection is configured to protect the gRPC service, the device is configured correctly.

If gRPC is enabled but Traffic Protection is not configured to protect the gRPC service, either configure Traffic Protection or migrate to a fixed release to leverage Management Interface filtering support of gRPC.

Proceed to **Step 3** only if evaluating the following Cisco products and releases:

* 8000 Series Routers that are running an IOS XR image earlier than the first fixed release
* NCS 540 Series Routers that are running an NCS540L-iosxr base image earlier than the first fixed release
* NCS 5700 Series Routers that are running an NCS5700 base image earlier than the first fixed release

Otherwise, stop here.

**Step 3: Determine the status of SSH**

To determine whether SSH is configured on a device, use the **show running-config ssh** CLI command. The following example shows the output on a device that has the SSH service enabled and configured. In this example, the device has both an IPv4 ACL and an IPv6 ACL configured against the SSH server:

>
>
> “`
> RP/0/RP0/CPU0:Router#**show running-config ssh**\
> Wed Sep 9 16:00:00.000 UTC\
> **ssh server v2 \
> ssh server** vrf mgmt **ipv4 access-list**SSH_ACL_Ingress **ipv6 access-list** SSH_ACL_Ingress\
> \
> RP/0/RP0/CPU0:Router#
> “`
>
>

If SSH is enabled and IP ACLs are applied to the SSH service, the device is configured correctly.

If SSH is enabled but IP ACLs are not configured to protect the SSH service, either add the **ssh server ipv4|ipv6 access-list** configuration or migrate to a fixed release to leverage Management Interface filtering support of SSH.

Proceed to **Step 4**.

**Step 4: Determine the status of NETCONF over SSH**

To determine whether NETCONF over SSH is configured, use the **show running-config ssh server netconf** CLI command. The following example shows the output on a device that has NETCONF over SSH enabled and configured. In this example, the device has both an IPv4 ACL and an IPv6 ACL configured against the NetConf SSH server:

>
>
> “`
> RP/0/RP0/CPU0:Router#show running-config ssh server netconf\
> Wed Sep 9 16:00:00.000 UTC\
> **ssh server netconf** vrf mgmt **ipv4 access-list** NetConf_ACL_Ingress **ipv6 access-list** NetConf_ACL_Ingress\
> \
> RP/0/RP0/CPU0:Router#
> “`
>
>

If NETCONF over SSH is enabled and IP ACLs are applied to the NETCONF SSH service, the device is configured correctly.

If NETCONF over SSH is enabled but IP ACLs are not configured to protect the NETCONF SSH service, either add the **ssh server netconf ipv4|ipv6 access-list** configuration or migrate to a fixed release to leverage Management Interface filtering support of NETCONF SSH.

If it is configured to deny the ports that are configured for gRPC, SSH, or NETCONF over SSH, this is a match.
Step 2: Determine the status of gRPCTo determine whether gRPC is configured on a device, use the show running-config grpc CLI command.
Step 3: Determine the status of SSHTo determine whether SSH is configured on a device, use the show running-config ssh CLI command.
Step 4: Determine the status of NETCONF over SSHTo determine whether NETCONF over SSH is configured, use the show running-config ssh server netconf CLI command.
If NETCONF over SSH is enabled but IP ACLs are not configured to protect the NETCONF SSH service, either add the ssh server netconf ipv4|ipv6 access-list configuration or migrate to a fixed release to leverage Management Interface filtering support of NETCONF SSH.