How to remediate – Arista Networks EOS MPBGP Denial of Service (SA0029)

1. Introduction

Arista Networks EOS is affected by a denial of service vulnerability (SA0029). This occurs due to improper handling of malformed MPBGP updates, potentially causing a device to become unresponsive. Systems running Arista EOS are at risk. A successful exploit could lead to an interruption of network services. Impact on confidentiality is unlikely, but integrity and availability may be compromised.

2. Technical Explanation

The vulnerability stems from insufficient validation of MPBGP updates received by the affected versions of Arista EOS. An attacker can craft a malicious MPBGP packet that causes excessive resource consumption during processing, leading to a denial-of-service condition. The CVE associated with this issue is CVE-2017-8231. For example, an attacker could send a large number of malformed updates to overwhelm the device’s CPU and memory resources.

• Root cause: Improper processing of malformed MPBGP updates.
• Exploit mechanism: Sending crafted MPBGP packets to trigger excessive resource consumption.
• Scope: Arista Networks EOS. Affected versions should be checked against vendor documentation.

3. Detection and Assessment

To confirm vulnerability, check the installed EOS version. A thorough assessment involves monitoring device resources during simulated MPBGP traffic.

• Quick checks: Use the `show version` command to display the EOS software version.
• Scanning: Nessus plugin ID ea999555 may detect this vulnerability as an example only.
• Logs and evidence: Monitor CPU usage and memory consumption for unusual spikes during normal operation.

show version

4. Solution / Remediation Steps

The solution is to contact Arista Networks for a fixed version of EOS. Follow the steps below to prepare, implement, and verify the fix.

4.1 Preparation

• Stopping services is not typically required but review impact for your environment. A roll back plan involves restoring from backup or snapshot.
• A change window may be needed, depending on service impact and internal procedures. Approval should be obtained from the network team lead.

4.2 Implementation

1. Step 1: Contact Arista Networks support to obtain a fixed version of EOS.
2. Step 2: Download the updated EOS image from the vendor’s website.
3. Step 3: Follow the vendor’s instructions for upgrading EOS software. This typically involves using the `boot system` command in the CLI.

4.3 Config or Code Example

Before

show version 

After

show version 

4.4 Security Practices Relevant to This Vulnerability

Practices that can help mitigate this vulnerability include a robust patch management process and network segmentation. Least privilege reduces the impact if exploited, limiting the scope of affected systems.

• Practice 1: Implement a regular patch cadence for all network devices to ensure timely application of security updates.
• Practice 2: Network segmentation can isolate vulnerable devices from critical infrastructure.

4.5 Automation (Optional)

Automation is not typically available for EOS software upgrades, as it requires vendor-specific procedures and careful planning.

5. Verification / Validation

• Post-fix check: Run `show version` and confirm the output displays the new fixed version of EOS.
• Re-test: Repeat the initial vulnerability assessment steps to ensure the issue is resolved.
• Smoke test: Verify basic network connectivity by pinging a known host on the network.

show version

6. Preventive Measures and Monitoring

Update security baselines to include minimum EOS versions. Implement monitoring for CPU usage spikes that could indicate an attack. For example, configure alerts in your network management system to notify you of high CPU utilization on Arista devices.

• Baselines: Update the network device baseline configuration to specify a supported and patched version of EOS.
• Pipelines: Consider integrating vulnerability scanning into CI/CD pipelines for infrastructure-as-code deployments.
• Asset and patch process: Establish a regular review cycle for security patches and configurations.

7. Risks, Side Effects, and Roll Back

Upgrading EOS software can introduce compatibility issues or service disruptions. Always test in a non-production environment first. A roll back involves restoring the previous configuration from backup.

• Risk or side effect 1: Potential for temporary network outage during upgrade process. Mitigation is thorough testing and planning.
• Risk or side effect 2: Compatibility issues with existing configurations. Mitigation is reviewing release notes and testing changes.

8. References and Resources

• Vendor advisory or bulletin: http://www.nessus.org/u?ea999555
• NVD or CVE entry: CVE-2017-8231