Google Cloud Fix Blocks Unauthorized Container Access

Google fixed a vulnerability in its cloud computing services suite that attackers could have exploited to gain unauthorized access to container images. Researchers said the flaw highlights how services built atop other services can pose unexpected security risks.

See Also: Enhance Cloud Security with AI-Driven Technologies

This Google Cloud Platform vulnerability allowed an attacker with basic access permissions to a victim’s project to access a “private image” in a victim’s Container Registry “by injecting malicious instructions and tailoring a payload to the benefit of the attacker,” said a report released Tuesday by vulnerability management provider Tenable. It discovered and reported the flaw, which it dubbed ImageRunner, to Google.

“In a real-world scenario, an attacker would use this vulnerability for data theft or espionage,” said Liv Matan, the senior security researcher at Tenable who authored the report. “The attacker could use their code to inspect the contents of the private image, extract secrets stored within it, or even exfiltrate sensitive data.” In cloud computing, a container image contains everything required to execute a software application on a serverless infrastructure.

Tenable said the vulnerability is just the latest in a long line of layered security problems in cloud environments, likening securing the cloud to a game of Jenga. Players remove blocks from the bottom and place them on top, aiming to not be the one who loses by sending the tower crashing down (see: CloudImposer RCE Vulnerability Targets Google Cloud Platform).

Many providers will “build one service on top of the other, with ‘behind the scenes’ building blocks inheriting risky defaults from one layer to the next,” Matan said. “In the game of Jenga, cloud services are like the blocks. If one service is compromised, the other services built on top of it inherit the risk and vulnerability.”

Or as Tenable’s report says: “This scenario opens the door for attackers to discover novel privilege escalation opportunities and even vulnerabilities, and introduces new hidden risks for defenders.”

The problem involved a Google Cloud Run service agent responsible for pulling tasks. The flaw was that it didn’t first verify through its identity and access management system that the user had explicit read access to a containerized application, before allowing it to be deployed.

Google updated GCP on Jan. 13 to fix the vulnerability, having already alerted users that the update might break their current use of Artifact Registry, which handles container management and storage. The update’s release notes state: “The principal (user or service account) creating or updating a Cloud Run resource now needs explicit permission to access the container image(s). When using Artifact Registry, ensure the principal has the Artifact Registry Reader (roles/artifactregistry.reader) IAM role on the project or repository containing the container image(s) to deploy.”

Every time Cloud Run is deployed or updated, it creates a new “revision” that’s unique for that user’s specific service. Users first select which image to deploy from the available registries, using the Artifact Registry tool for storing and managing containers. Previously, users could also have employed the Container Registry tool, but on March 18 Google deprecated it in favor of Artifact Registry.

“Cloud Run pulls images during a revision deployment process,” Matan told Information Security Media Group. “Cloud Run uses a service agent, an automated ‘worker’ that handles essential operations, which has higher permissions allowing it to retrieve images from the Google Container Registry or Artifact Registry. By injecting malicious instructions, an attacker could inspect sensitive data within these images.”

Attackers would have needed to gain basic run.services.update and iam.serviceAccounts.actAs permissions, allowing them to “modify a Cloud Run service and deploy a new revision,” Tenable said. By injecting the malicious instructions, “they could specify any private container image within the same project for the service to pull,” allowing them to bypass “these two permissions required to pull private images from the registry: Storage Object Viewer or Artifact Registry Reader.”