Google paid $90,000 for a Flask pickle bug on its developer sites

A session cookie that an application signs with a secret, and that also contains the secret inside its own data, is a shape nobody should ship. Security researcher Simon Koeck found that exact shape on five of Google's developer sites, and used it to execute arbitrary code on Google's servers through a chain of two short Python errors. Google paid him $90,000, the full $75,000 S0 remote code execution reward plus a 1.2 multiplier for report quality.

The affected hosts were developers.google.com, firebase.google.com, developer.android.com, source.android.com, and docs.partner.android.com. Koeck reported the bug on 6 August, Google triaged it the next day, settled the reward on 27 August, and shipped the fix on 7 October. Discussion of the writeup reached 227 points on Hacker News.

What the bug looked like

The Flask app signed each session cookie with a SECRET_KEY that was identical to the OAuth client secret the cookie's payload also stored, in plaintext. An attacker could read the OAuth secret from any valid session cookie, use it as the signing key to forge any session they wanted, and the OAuth callback would unpickle whatever payload came back inside that forged session.

The second half of the chain is what any Flask developer learns in a security course. pickle.loads on untrusted data runs arbitrary code: the pickle format carries a REDUCE opcode that calls any callable the attacker names with any arguments. Koeck demonstrated this with a payload that called time.sleep for a given number of seconds and measured the response delay to confirm the code had run, rather than opening a shell on Google's infrastructure.

The pattern worth searching your own code for

Two rules protect against this shape of bug, and both are standard. First, a signing secret never belongs in the signed data: if the data is readable, the secret is readable, and the signature protects nothing. Second, no application should unpickle data that reached it from the network, however many signatures the data carries, because a trusted sender can still send a payload a different machine prepared.

Flask's own documentation says the same thing, and the itsdangerous library it ships with uses JSON serialisation by default for signed cookies, specifically to avoid this class of bug. The vulnerable code at Google was not using the stock session interface but a custom OAuth2 flow object that was pickled into the session, so the Flask default did not help.

A one-afternoon audit worth doing on a Python codebase: grep for pickle.loads, follow each one back to the data it reads, and ask whether that data was prepared by somebody the application trusts to run code on it. If the answer is no, replace the call with JSON parsing or a signed serializer that refuses the opcode set. The same grep works for yaml.load without a safe loader and marshal.loads, both of which carry the same category of problem.

The two-month window Google took to deploy the fix is its own problem: a bounty is paid against severity, and S0 remote code execution against five production hosts is as serious as the Google programme ranks a web bug. The engineering work after triage is where the question sits, and the writeup does not try to answer it.

Source

I Found a $90k Remote Code Execution Vulnerability in Google, by Simon Koeck on his blog.