CVE-2020-9480: Apache Spark Auth Bypass Vulnerability

CVE-2020-9480 Overview

In Apache Spark 2.4.5 and earlier, a standalone resource manager's master may be configured to require authentication (spark.authenticate) via a shared secret. When enabled, however, a specially-crafted RPC to the master can succeed in starting an application's resources on the Spark cluster, even without the shared key. This can be leveraged to execute shell commands on the host machine. This does not affect Spark clusters using other resource managers (YARN, Mesos, etc).

Critical Impact

This authentication bypass vulnerability (CWE-306: Missing Authentication for Critical Function) allows unauthenticated remote attackers to execute arbitrary shell commands on Apache Spark standalone clusters, potentially leading to complete system compromise.

Affected Products

• Apache Spark versions 2.4.5 and earlier (standalone resource manager mode)
• Oracle Business Intelligence 5.5.0.0.0 Enterprise Edition

Discovery Timeline

• 2020-06-23 - CVE-2020-9480 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2020-9480

Vulnerability Analysis

This vulnerability represents a critical authentication bypass flaw in Apache Spark's standalone resource manager. The core issue lies in how the Spark master processes RPC (Remote Procedure Call) requests when authentication is enabled via the spark.authenticate configuration option. Despite authentication being configured with a shared secret, the vulnerability allows specially-crafted RPC messages to bypass the authentication check entirely.

The flaw is classified under CWE-306 (Missing Authentication for Critical Function), indicating that the authentication mechanism fails to properly validate credentials for critical operations. Once exploited, an attacker can start application resources on the Spark cluster without possessing the shared authentication key, effectively bypassing the security boundary entirely.

Root Cause

The root cause stems from incomplete authentication enforcement in the RPC handling logic of Apache Spark's standalone master component. When the spark.authenticate setting is enabled, the system should require all incoming RPC requests to present valid credentials derived from the shared secret. However, certain RPC message types or request paths were not properly covered by the authentication checks, creating a gap that allows unauthenticated requests to reach privileged functionality.

This architectural oversight means that even when administrators believe their Spark cluster is protected by shared secret authentication, the protection is incomplete and can be circumvented by attackers who understand the vulnerable request patterns.

Attack Vector

The attack is network-based and requires no user interaction or prior authentication. An attacker with network access to the Spark master's RPC port can craft malicious RPC messages that exploit the authentication bypass. The attack proceeds as follows:

1. The attacker identifies a Spark standalone cluster with the master accessible over the network
2. A specially-crafted RPC request is sent to the master that bypasses authentication checks
3. The attacker's request initiates application resources on the cluster
4. Once resources are allocated, the attacker can leverage Spark's execution capabilities to run arbitrary shell commands on worker nodes

The vulnerability is particularly dangerous because it directly leads to remote code execution, allowing attackers to gain shell access on the host machines within the Spark cluster. This can result in data theft, lateral movement, installation of malware, or complete infrastructure compromise.

Detection Methods for CVE-2020-9480

Indicators of Compromise

• Unexpected application submissions appearing in Spark master logs without corresponding authenticated sessions
• Anomalous RPC traffic to the Spark master port (default 7077) from unknown or external sources
• Unauthorized job executions or shell processes spawned by Spark executor processes
• Network connections to/from Spark worker nodes that do not correlate with legitimate workloads

Detection Strategies

• Monitor Spark master logs for application submission events and correlate with authenticated user sessions
• Implement network-level detection for RPC traffic patterns targeting Spark master services, particularly from untrusted network segments
• Deploy endpoint detection on Spark cluster nodes to identify suspicious child processes spawned by executor JVM processes
• Utilize SentinelOne's behavioral AI to detect post-exploitation activities such as unauthorized shell command execution

Monitoring Recommendations

• Enable verbose logging on Apache Spark master and worker components to capture detailed RPC interaction logs
• Implement network segmentation and monitor for any attempts to access Spark master ports from outside trusted management networks
• Set up alerts for new application submissions, especially those occurring outside of normal operational windows
• Monitor system-level process creation events on Spark nodes for execution of unexpected binaries or scripts

How to Mitigate CVE-2020-9480

Immediate Actions Required

• Upgrade Apache Spark to version 2.4.6 or later, which contains the fix for this vulnerability
• Restrict network access to Spark master RPC ports (default 7077) to only trusted internal networks and management systems
• If using Oracle Business Intelligence with embedded Spark components, apply the patches referenced in Oracle Security Alert April 2021
• Audit existing Spark clusters for signs of exploitation before and after patching

Patch Information

Apache has released a fix for this vulnerability in Apache Spark version 2.4.6 and later releases. Organizations should upgrade to the latest stable version of Apache Spark as soon as possible. For detailed information on the vulnerability and patching guidance, refer to the Apache Spark Security Page for CVE-2020-9480.

Oracle customers using Business Intelligence 5.5.0.0.0 Enterprise Edition should consult the Oracle April 2021 Critical Patch Update for applicable patches and remediation guidance.

Workarounds

• Implement strict network segmentation to ensure the Spark master RPC port is not accessible from untrusted networks
• Use firewall rules to allow connections to the Spark master only from known and trusted IP addresses
• Consider deploying Spark clusters behind a VPN or other network access control mechanism until patching can be completed
• Switch to alternative resource managers such as YARN or Mesos that are not affected by this specific vulnerability

# Example: Restrict access to Spark master port using iptables
# Allow only internal management network (10.0.0.0/24) to access Spark master
iptables -A INPUT -p tcp --dport 7077 -s 10.0.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 7077 -j DROP