Item — HN Reader

I mean this is a clever hack, but it is not a Google vulnerability per se, it is a vulnerability in a public open source tool chain that they use, i.e. pip.

It is working more or less exactly as it should, the employees in question are just downloading untrusted packages inadvertently. This is something that could happen anywhere, even without private package repos.

3 comments

I guess pip wouldn’t pay the researcher cash, so they’re not interested in that. This blog seems like a pretty desperate attempt to get google to pay them.

I think my response would be two words and the second one would be off.

> This blog seems like a pretty desperate attempt to get google to pay them.

It's actually deliberately criminal as I read it. "Hey, I trojaned some code and got it downloaded onto your company's systems! Please pay me a bug bounty!" is 100% isomorphic to extortion.

It is not extortion unless a threat is being made, and you cannot manufacture a threat against yourself by claiming that the author might conceivably make a threat on the basis of these facts, particularly when you have also said that these facts raise no concerns.

There is no credible threat here. In addition to the above points, if attacks were made by exploiting these facts, the author, having raised the issue in the first place, would become a person of interest in any investigation.

“Ladies and gentlemen of the jury, my client did not threaten anyone! His accusers are on record as saying he merely told them that they had a, quote, ‘nice little restaurant’, and that it would be a ‘shame if it caught fire’. These are not threats, but simply facts.”

Sigh... this is why I wrote "credible threat". There is no credible threat here.

He literally compromised live systems. You're using "credible" in the sense that you take him at his word that he won't do anything bad. That's exactly the wrong party to be playing trust in!

Your response here has failed to address any of the points I made in my original reply. You have not identified any threat being made, without which there is no extortion - and as Google does not regard this situation as being a vulnerability, it is going to be difficult for you to identify a credible threat that could be used to extort something from them.

Notice that you are also taking the author at his word when you say he literally compromised live systems. To turn this into a case of extortion, you would have to go beyond that and invent a number of things that have not been said - and some highly implausible things at that, given the very public way in which this supposed extortion is being conducted.

Can you describe a credible submission to a bug bounty that isn't "100% isomorphic to extortion"?

Any submission without an exploit? It's routine to find crash bugs or potentially XSS data or injection opportunities without going all the way to a compromised system.

The issue here is that the submit actually attacked live systems, instead of just reporting on the possibility of malicious library code.

...which is something everyone already knows about, and thus why he couldn't get paid. You don't get paid for actually hacking systems either!

Most bug bounties against remote systems are criminal.

That’s like saying it’s not a bank vulnerability for using a gate made of paper instead of steel. It’s a vulnerability of the paper...

It is a google vulnerability for using the tool in ways that are known to be broken. Dependency confusion attacks are well known and have known mitigations. When depending on private packages one must not rely only on extra-index-url, instead point to a full url or use a completely internally hosted index-url.

I mean, this guy just registered a package without mentioning it to anyone, then suddenly it started executing inside a google users machine. No social engineering involved. Note that pip install is not just downloading, it also can run arbitrary code during installation phase due to setup.py.

Sure, Google likely have another 3 layers of defense to get to the truly interesting sauce, at least he got through the front door.

Call it whatever, but executing arbitrary code on an employee's system should trigger all the alarms in any org.

The two guys responding to the email are basically "doing their job". "Oh, it's not a bug in the software package, no cookie for you." Yeah, it's a much more severe incident, you stupid son of a bitch. Any CISO sees this and throws themselves out of the window.

Can you please edit out name-calling and swipes from your HN posts, and make your substantive points thoughtfully?

You obviously had a good point here but including things like "you stupid son of a bitch" unfortunately flips a higher-order bit. Perhaps you don't owe inadequate vulnerability handlers better, but you owe this community better if you're participating in it.

If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.

Google implements a zero-trust security model[0] they call BeyondCorp[1], which basically assumes any device may be compromised at any given moment. I'm not intimately familiar with their implementation but it seems designed to make precisely situations like this less dramatic.

[0] https://en.wikipedia.org/wiki/Zero_trust_security_model

[1] https://beyondcorp.com

Their paper is probably also a useful cite here https://research.google/pubs/pub43231/

I hate to break this to you, but engineers themselves are capable of running arbitrary malicious code on their own workstations, even if we ignore the dozen other ways it might get there (dependency attacks, social engineering, browser exploits, plugging in a USB key you found on the ground, etc.).

At Google’s scale you need to assume that even some employees will be bad faith actors (e.g. agents of some government, with a goal of surreptitiously adding back doors) and you need far more sophisticated security controls (e.g. multi-party controls, immutable audit trails) than assuming engineers or their systems will never be compromised. The latter is going to be true for some employee nearly 100% of the time even if you don’t have bad actors.

The existence of these controls and general set of security assumptions and architecture are what make this not a big deal, not a lack of care.

Eh. Google has serious insider risk protection and a intends to defend against arbitrarily malicious single employees. "Somebody runs something bad on their workstation" is already a threat model that they've been working to mitigate for like a decade.

How do you suggest they prevent this?

Namespacing packages plus private (or public) pip patch that hardcodes the link of certain namespaces to certain repos would be the most obvious one (I spent 5 seconds thinking about it so far not I'm not saying it's the best ever).

Internal package registry that knows all internal package names and makes pip reject colliding names from other sources would be another possibility.

Explicitly verifying the hash of the internal package based on the registry (again) and refusing to install packages that don't match the hash would be another option.

I'm sure if a person smarter than me (Google probably has thousands) spends a day thinking about it, they could think of a dozen better ways.

Are you saying it's impossible to mitigate/eliminate package source confusion attacks? There's no way in Python to pin the source exactly where Google wants it?

It's possible to mitigate, but it's impossible to realistically prevent unless you disconnect your employees from the internet. Which is probably costlier than any losses they are ever likely to end up having due to this.

There is a universe of difference between "employee is allowed to download from the internet" and "something unintended from an unauthorized external party runs automatically"

come the fuck on

Any package from pypi can at any time run code that’s malicious. IIRC, even at install time. So installing any package, even in a python virtual environment bears the risk of arbitrary code execution - before you have a chance to inspect it. (Same for php, ruby, rust, …) Basing your security concept on that never happening is like playing whack-a-mole in hardcore mode.

And "employee ignores the threat despite being told repeatedly about it".

I don't know where some HN folks get their logic from.

What are you going to do? Block access to any pypi.org package except for whitelisted ones? You can try to mitigate things by perhaps blocking access to any pypi repos that's also available internally but that haven't been released to the public. At least it would get rid of this one vector. But that doesn't mean that people won't just "pip install whatever" anyway.

To quote John Oliver: "What can you do?" "Something. You can do, something."

The possible ways to respond to that process are open ended and infinite. You can do anything you want about it. Doing nothing about it is approximately the least defensible.

It's not very big when it comes to package management.

Essentially it’s impossible. You can make it harder, but if you grant developer machines access to the internet, they can download an untrustworthy package from anywhere and use it as a local dependency.

You can protect production and CI systems by restricting their internet access, but who can reasonably do work with such a restriction.

There's a big difference from a person downloading a package from a random site and running it, and a person adding a known internal package name to requirements.txt. The first is usually a bad idea (unless you know what you're doing and ready for the consequences) and every SWE worth Google money knows that. The second is a standard practice and everybody does that. You can't make stupid behavior impossible - but you can make common behavior safe, and that's the basis of good security.

I agree with your general thrust, but I don’t see how your point refutes mine.

First, it’s not required to actually run the package. Installing it is sufficient. All package managers that I worked with so far can run code at install time.

Second, the issue here seems to be a misconfiguration that makes pip look up a private package that should be retrieved from a private repository on the public repository. The attacker then just registers a malicious package on the public repo with the same name. Preventing this attack requires that python is correctly configured on each an every developer machine - something that I’d never rely on as cornerstone of my security.

Third: This is one example of smuggling a malicious package on a developers machine. Another vector is that a good package turns into a malicious package with an update. That’s even harder to defend against - pulling in the update with the programming languages standard tooling may run malicious code. You can certainly first download the package, unpack and inspect it and then pull the update - but would you rely on thousands of developers diligently doing that?

Last: this class of error affects almost all programming language package managers out there.

So it’s better to assume that this will happen, take a local compromise of a developers machine as a matter of when, and mitigate what the attacker can do with the capabilities they gain from this compromise.

> Second, the issue here seems to be a misconfiguration that makes pip look up a private package that should be retrieved from a private repository on the public repository

True enough. The problem is that a) it is a common misconfiguration and b) it appears to be also affecting Google, which is a big juicy target for any computer criminal. We're not talking about solving a theoretical problem in 100% of theoretical cases. We're talking about having a very practical vulnerability - which can be practically fixed. Yes, that doesn't fix all other theoretically possible vulnerabilities - so what? That's like arguing that since halting problem is unsolvable having debuggers and static analyzers is useless - we can't solve 100% of the problem, so why even bother to solve even 1%?

> Last: this class of error affects almost all programming language package managers out there.

Again, you're replacing a specific issue with a "class". Yes, you can't fix all the problems in the whole class. But you can very well fix this particular one, in many ways.

You could work with a whitelist or a build environment that is sandboxed somehow.

As I understand the article, the problem is that an employee machine is misconfigured and uses the public package repo for a private package. The package in question seems to be explicitly pinned in the requirements.txt - that’s essentially a whitelist. Whitelisting also suffers from the issue that a good public packages could at any time turn into a malicious package - so you’d need to pin the version. A task that seems infeasible for developer machines at googles scale.

Sandboxing the development environment could be done, but would only help against this attack if the sandbox cannot connect to the public internet- which again would be painful.

Googles strategy of accepting that this kind of breach will happen and rather focus on mitigation of the resulting damage seems like the better way.