Arista EOS is not vulnerable to CVE-2020-9015

Recently a third party submission was made to MITRE’s CVE database about a possible vulnerability in Arista EOS products. This vulnerability was given the identifier CVE-2020-9015 and can be viewed here: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9015. This post is to discuss how this CVE was submitted in error and clarify that Arista EOS is not vulnerable to the issue discussed in the CVE.

Before discussing the issue itself, it is worth noting that the CVE database is a public database, which accepts submissions from anyone. If a report is disputed, as is the case with this one, MITRE will not attempt to take sides and determine which party is correct. MITRE will instead post the information each side has given and let readers decide which side they wish to listen to. This post represents the viewpoint of Arista Networks regarding this CVE.

On its surface this would appear to be a way to bypass authorization controls when network operators have configured TACACS+ as a remote authority for authorization by using the “pipe” ( | ) character in EOS CLI commands.

The post which was used to raise this CVE described a TACACS+ configuration which authorized pipe commands in the following manner:

cmd = | {
permit /^grep .*/
}

This could be translated, from its regex form to English, as ‘If the command being checked for authorization is “|”, allow it, if and only if, it begins with “grep”, a space, and any text.”

It is important to note at this point that TACACS+ is a protocol which EOS interoperates with, but that the TACACS+ server is not an Arista product nor are the settings on the device under Arista control. The server configuration and settings are the decision of the network operator.

The “E” in “EOS” stands for “Extensibility” and providing network operators with the freedom to perform advanced linux operations is something that Arista takes pride in. However, with great power, comes great responsibility. The Arista EOS Hardening Guide ( https://eos.arista.com/arista-eos-hardening-guide/ ) shows in multiple places that the pipe operator should only be allowed to be used by the highest authorized network operator managing the switch. This is because the pipe operator is tied to the bash shell. Piping the output of a command will make it the input of another command run on the bash shell. This is exactly what one familiar with Linux systems would expect to happen. The command help also mentions that free form commands will be run by Linux tools:

switch#show version | ?

LINE Filter command by common Linux tools such as grep/awk/sed/wc
append Append redirected output to URL
begin Start output at the first matching line
exclude Do not print lines matching the given pattern
include Print lines matching the given pattern
json Produce JSON output for this command
no-more Disable pagination for this command
nz Include only non-zero counters
redirect Redirect output to URL
section Include sections that match
tee Copy output to URL

Now, if one combines the above TACACS+ rules and a malicious intent, what could they do? The following command illustrates the potential damage:

show version | grep whatever | shutdown -t now

This command is passed to TACACS+ for authorization in 2 parts

“show version” – an EOS command

“|” – The pipe operator on the EOS CLI, with a bash command of “grep whatever | shutdown -t now”

This meets the TACACS+ rules, since they permitted the processing of any bash command starting with “grep”. It is also very unlikely that this is what the network operator who manages the TACACS+ server intended.

How can one avoid this issue? The EOS Hardening Guide provides a clear solution: only allow the most trusted network operators to use the pipe command. Other operators should not be allowed to use the command. It is possible to come up with a set of regex’s that would allow “|” to be used in a grep regex but not in a bash shell pipe, but attempts to do so would be difficult to verify and could break over time due to configuration changes from well meaning network operators.

As stated above, the only way to become a victim of this issue is if the network operator neglects the advice of the EOS Hardening Guide and makes the pipe operator available with an overly permissive regex in TACACS+. Since this requires willful effort of the network operator to modify a component that Arista does not control, this CVE is not considered an actual issue by Arista.

If in doubt on how to setup EOS securely, the Arista EOS Hardening Guide is always the first resource recommended to start with. If a reader has questions afterwards, TAC and customer account teams can be contacted to receive personalized advice. Finally, if any customer or third party believes a security issue related to any Arista product is suspected or discovered, the Arista security advisory page (https://www.arista.com/en/support/advisories-notices ) contains contact email information and a public PGP key for communication with the Arista Product Security Incident Response Team.

As a reminder, the Arista Security Response team requested MITRE to remove this CVE, which they declined as a matter of policy. We leave it to the community to decide if the use of a Linux pipe operator to send commands to a TACACS+ server is a misconfiguration of the server or a valid security vulnerability.

Recent Questions

DISCLAIMER:While this platform is not officially monitored by Arista Networks, Arista affiliated persons, including Arista employees, will periodically contribute. Arista affiliated persons are not authorized Arista spokespeople and contributions posted to this forum by Arista Networks employees, partners, and customers do not necessarily represent the position or view of Arista Networks.

This forum is NOT to be used for official Arista Networks product technical support. For technical support of any Arista product, please contact Technical Support at support@arista.com.