Under certain circumstances on affected platforms running Arista EOS with gRPC Network Packet Sampling Interface (gNPSI) enabled, the gNPSI client credentials might be logged in clear text in local or remote accounting logs to authenticated users.
On affected platforms running Arista EOS with VRRPv2 IP-AH authentication configured, an unauthenticated attacker within the same layer 2 network segment on which VRRP is running can capture a legitimate authenticated VRRP advertisement and replay it indefinitely. Replayed advertisements can be used to advertise stale VRRP state, for example to prevent a backup router from taking over the virtual gateway after the original master has gone down, resulting in a denial of service for hosts using the virtual gateway address.
When specific platforms are using Arista EOS with a loose Unicast Reverse Path Forwarding (uRPF) configuration, certain traffic may not be subjected to the intended verification drop. Consequently, traffic that should be dropped based on these routes could still be processed and forwarded by the device.
This issue was discovered internally by Arista and the company is not aware of any malicious uses of this issue in customer networks.
On affected platforms running Arista EOS, when multiple gRPC Network Security Interface (gNSI) transports are configured, a race condition in the gNSI Authz service may cause a policy rotation to fail silently. An authenticated user whose access was revoked by the new policy may retain unauthorized access to gRPC interfaces. This does not affect Bootz.
This issue was discovered internally by Arista, and the company is not aware of any malicious exploitation of this vulnerability in customer networks.
On affected platforms running Arista EOS with OpenConfig-related services (i.e., gNMI, gNSI, RESTCONF and NETCONF), sensitive requests and responses may be unintentionally logged. These may be stored on the local EOS device or recorded on remote accounting servers. Note that gRPC-based streaming via Streaming Telemetry Agent to CloudVision is not affected by this vulnerability.
Examples of sensitive information include: - Sensitive CLI commands (e.g., "username bob secret myPass") - Sensitive OpenConfig YANG leafs (e.g., "system/aaa/global/tacacs/config/secret-key")
This issue was discovered internally by Arista, and the company is not aware of any malicious exploitation of this vulnerability in customer networks.
On affected platforms running Arista EOS with gRPC Network Management Interface (gNMI) enabled, a specially crafted request could allow a malicious authenticated client with gRPC Network Management Interface (gNMI) access to execute arbitrary code with root privileges on the switch.
On affected EOS platforms with AAA-based gRPC authorization enabled for OpenConfig, gRPC requests of an authenticated user to OpenConfig may use the wrong privilege level, resulting in an authorization using the wrong AAA method list. This does not impact non-gRPC OpenConfig requests such as NETCONF.
On affected platforms running Arista EOS with MLAG Dual Primary Detection configured, an unauthenticated attacker with access to the Dual Primary Detection network segment can send specially crafted packets to interfere with the dual-primary state. If the MLAG primary switch fails while these packets are present, the secondary switch incorrectly concludes it is in a dual-primary condition and err-disables its interfaces, leading to a traffic interruption.
On affected platforms running Arista EOS with IS-IS graceful restart enabled, an unauthenticated attacker who can inject a malformed IS-IS LSP PDU packet can cause the IS-IS graceful restart procedure to terminate prematurely. This may result in traffic loss following a restart event.
On affected platforms running Arista EOS with VRRPv2 IP Authentication Header (IP-AH) authentication configured, an unauthenticated attacker with access to the layer 2 network segment on which VRRP is running could bypass VRRP authentication and claim the virtual router master role, enabling the attacker to intercept, modify, or discard traffic that hosts on the segment send to the virtual gateway address.
On affected platforms running Arista EOS with password authentication configured, a specially crafted password can create orphan authentication sessions. Repeated exploitation of this issue can exhaust available authentication resources, resulting in legitimate users being unable to log in to the device.
This issue was discovered internally by Arista, and the company is not aware of any malicious exploitation of this vulnerability in customer networks.
On affected platforms running Arista EOS with dual switch cards and with ingress Security ACLs configured on Switched Virtual Interfaces (SVI) in shared mode, restarting of the secondary switchcard forwarding agent or insertion of secondary switchcard, can cause security ACLs on shared SVIs to stop functioning. This may result in incorrect packet permit/deny behavior.
This issue was discovered internally by Arista, and the company is not aware of any malicious exploitation of this vulnerability in customer networks.
An authenticated supplicant on an adjacent network may bypass intended network authorization policy and send unrestricted traffic during a brief window (milliseconds to seconds) between the completion of the authentication phase and the full enforcement of its assigned ACL.
On affected platforms running Arista EOS with both 802.1X port authentication and the RADIUS proxy feature configured with dynamic authorization, a low-privileged attacker on an adjacent network segment who induces a RADIUS packet through a configured RADIUS proxy client can prevent RADIUS dynamic authorization messages, including Change-of-Authorization (CoA) and Disconnect-Requests as defined in RFC 5176, from being applied to locally authenticated 802.1X sessions. This allows an endpoint session that a RADIUS server or network access control system has ordered disconnected to remain authorized on the network. Both 802.1X port authentication with dynamic authorization and RADIUS proxy with dynamic authorization must be explicitly configured for a deployment to be exposed to this issue. This issue was discovered internally by Arista, and the company is not aware of any malicious exploitation of this vulnerability in customer networks.
Arista Extensible Operating System (EOS) contains an incomplete comparison with missing factors vulnerability when the switch incorrectly decapsulate and forwards other unexpected tunneled packet with a destination IP matching its configured decapsulation IP.
Affected platforms running Arista EOS with OpenConfig configured, a gNMI Set request can be run when it should have been rejected. This can result in unexpected configuration being applied to the switch.
In Arista’s EOS when in 802.1X mode, multi-auth unauthenticated hosts might be allowed access to a switch port if there exists an EAPOL capable device in the fallback VLAN.
On affected platforms running Arista EOS with MACsec configuration, a specially crafted packet can cause the MACsec process to terminate unexpectedly. Continuous receipt of these packets with certain MACsec configurations can cause longer term disruption of dataplane traffic.
On affected platforms running Arista EOS with OSPFv3 configured, a specially crafted packet can cause the OSFPv3 process to have high CPU utilization which may result in the OSFPv3 process being restarted. This may cause disruption in the OSFPv3 routes on the switch.
This issue was discovered internally by Arista and is not aware of any malicious uses of this issue in customer networks.
On affected platforms running Arista EOS, certain serial console input might result in an unexpected reload of the device.153
n affected platforms running Arista EOS, ACL policies may not be enforced. IPv4 ingress ACL, MAC ingress ACL, or IPv6 standard ingress ACL enabled on one or more ethernet or LAG interfaces may result in ACL policies not being enforced for ingress packets. This can cause incoming packets to incorrectly be allowed or denied. The two symptoms of this issue on the affected release and platform are:
Packets which should be permitted may be dropped and, Packets which should be dropped may be permitted.
On affected platforms with hardware IPSec support running Arista EOS with IPsec enabled and anti-replay protection configured, EOS may exhibit unexpected behavior in specific cases. Received duplicate encrypted packets, which should be dropped under normal anti-replay protection, will instead be forwarded due to this vulnerability.
Note: this issue does not affect VXLANSec or MACSec encryption functionality.
On affected platforms running Arista EOS, ingress traffic on Layer 2 ports may, under certain conditions, be improperly forwarded to ports associated with different VLANs, resulting in a breach of VLAN isolation and segmentation boundaries.
On affected platforms running Arista EOS with Traffic Policies configured the vulnerability will cause received untagged packets not to hit Traffic Policy rules that they are expected to hit. If the rule was to drop the packet, the packet will not be dropped and instead will be forwarded as if the rule was not in place. This could lead to packets being delivered to unexpected destinations.
On affected platforms running Arista EOS with secure Vxlan configured, restarting the Tunnelsec agent will result in packets being sent over the secure Vxlan tunnels in the clear.
On affected platforms running Arista EOS with a gNMI transport enabled, running the gNOI File TransferToRemote RPC with credentials for a remote server may cause these remote-server credentials to be logged or accounted on the local EOS device or possibly on other remote accounting servers (i.e. TACACS, RADIUS, etc).
On affected platforms running Arista EOS with 802.1X configured, certain conditions may occur where a dynamic ACL is received from the AAA server resulting in only the first line of the ACL being installed after an Accelerated Software Upgrade (ASU) restart.
Note: supplicants with pending captive-portal authentication during ASU would be impacted with this bug.
On affected platforms running Arista EOS with BGP Link State configured, BGP peer flap can cause the BGP agent to leak memory. This may result in BGP routing processing being terminated and route flapping.
On affected platforms running Arista EOS with OpenConfig configured, a gNOI request can be run when it should have been rejected. This issue can result in unexpected configuration/operations being applied to the switch.
On affected platforms running Arista EOS with OpenConfig configured, a gNOI request can be run when it should have been rejected. This issue can result in users retrieving data that should not have been available