Regulation

Google's $90K Bug Fix: Two-Month Delay Raises Questions About DevSite Security Flaw

A researcher discovered an OAuth secret reused as a signing key across Google's developer documentation servers, enabling unauthenticated remote code execution. Google awarded a $90,000 bounty but took two months to deploy the patch.

4 min read
Google paid $90,000 for this bug, then waited two months to fix it

Simon Köck, a software engineer at Otark GmbH, uncovered a critical vulnerability in Google's DevSite infrastructure, the underlying platform powering developers.google.com and related documentation portals. The flaw stemmed from an OAuth secret that simultaneously functioned as a signing key, creating a pathway for remote code execution without authentication. Köck's research revealed the same signing secret was active across seven distinct Google domains, though his public documentation of the exploit focused on developers.google.com.

Google rated the vulnerability S0, the top of its severity scale, and awarded Köck a $90,000 bounty. The bounty amount consisted of a $75,000 baseline for an S0 remote code execution vulnerability in what Google categorizes as a normal application tier, adjusted upward by a factor of 1.2 to recognize the quality of the report.

Köck demonstrated unauthenticated RCE by deploying a Python sleep payload, deliberately avoiding shell command execution or access to sensitive information. This restraint left unresolved the question of what capabilities an attacker might have wielded given the privileges of the DevSite process itself.

One potential concern involves the possibility that an attacker could have altered Google's developer documentation, substituting installation instructions or download URLs with malicious alternatives. Such a scenario could have constituted a supply-chain attack, but Köck refrained from testing write permissions to content systems. Google has also declined to disclose DevSite's process permissions or backend access controls, leaving the full scope of potential damage unclear.

One OAuth secret, two jobs

Köck established that Google had repurposed the OAuth client secret as the signing key for DevSite's Flask session cookies by recreating the cookie signature outside the server environment. This key allowed him to construct sessions that the server would validate as legitimate.

The cookie contained a serialized OAuth2WebServerFlow object from Google's deprecated oauth2client library, which the company has since replaced with google-auth. Köck substituted this object with a malicious pickle payload and signed the fabricated cookie. When the OAuth callback deserialized the session, the payload ran.

To confirm RCE, Köck leveraged Python's time.sleep() function and observed the resulting delays in server responses. The measured delays aligned with his payload specifications, establishing code execution had occurred without requiring shell command invocation or data extraction.

Pickle turns forgery into RCE

DevSite stored a serialized OAuth flow object within a Flask session cookie, inadvertently exposing its client secret in the process. Because Google had also used that secret to sign the cookie, Köck possessed the ability to forge sessions the server would accept.

The OAuth callback relied on Python's pickle module to deserialize session data, enabling Köck's payload to execute. He chained all three vulnerabilities together: forging a signed cookie containing a malicious pickle payload that executed during OAuth callback processing.

Köck exploited all three issues in sequence, forging a signed cookie with a malicious pickle payload that executed when the OAuth callback processed it.

Remediation of any single issue would have interrupted this chain, but their combination transformed DevSite's OAuth flow into an unauthenticated RCE vulnerability.

Patch pace raises questions

Köck submitted his findings on August 6, with Google acknowledging receipt the next day. The company greenlit the bounty on August 27 but withheld deployment of a fix until October 7.

Google has not clarified the reasoning behind the two-month remediation timeline or whether it deployed temporary protective measures during that interval. Uncertainty also surrounds the nature of the fix itself.

Köck says seven domains were affected but publicly identified only five.

Köck identified seven affected domains in his analysis but disclosed only five publicly. His recommendations reference two exposed OAuth client secrets, yet Google has not confirmed whether both underwent rotation or if existing sessions were invalidated. The company has also refrained from stating whether it discovered signs of prior exploitation before implementing the patch.

Attempts to reach Google and Köck for additional comment yielded no response before publication.

Source: The New Stack · Reporting supplemented by The Silicon Ledger staff.