11 ms·

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

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.

juunpp 4y ago
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.
- dataflow 4y ago
  How do you suggest they prevent this?
  - mixdup 4y ago
    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?
    - aflag 4y ago
      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.
      - Brian_K_White 4y ago
        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
        juunpp 4y ago
        And "employee ignores the threat despite being told repeatedly about it". I don't know where some HN folks get their logic from.
        robertlagrant 4y ago
        It's not very big when it comes to package management.
        Xylakant 4y ago
        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.
        aflag 4y ago
        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.
        Brian_K_White 4y ago
        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.
    - Xylakant 4y ago
      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.
      - jacquesm 4y ago
        You could work with a whitelist or a build environment that is sandboxed somehow.
        Xylakant 4y ago
        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.
      - smsm42 4y ago
        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.
        Xylakant 4y ago
        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.
  - smsm42 4y ago
    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.
- notduncansmith 4y ago
  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 https://en.wikipedia.org/wiki/Zero_trust_security_model [1] https://beyondcorp.com https://beyondcorp.com
  - kristjansson 4y ago
    Their paper is probably also a useful cite here https://research.google/pubs/pub43231/ https://research.google/pubs/pub43231/
- amscanne 4y ago
  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.
- shdwband 4y ago
  [flagged]
- UncleMeat 4y ago
  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.
- dang 4y ago
  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 https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
mnd999 4y ago
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.
- ajross 4y ago
  > 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.
  - charcircuit 4y ago
    Most bug bounties against remote systems are criminal.
  - deleted 4y ago
    [deleted]
  - scubbo 4y ago
    Can you describe a credible submission to a bug bounty that isn't "100% isomorphic to extortion"?
    - ajross 4y ago
      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!
  - mannykannot 4y ago
    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.
Too 4y ago
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.

juunpp 4y ago

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.

dataflow 4y ago
How do you suggest they prevent this?
- mixdup 4y ago
  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?
  - aflag 4y ago
    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.
    - Brian_K_White 4y ago
      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
      - juunpp 4y ago
        And "employee ignores the threat despite being told repeatedly about it". I don't know where some HN folks get their logic from.
      - robertlagrant 4y ago
        It's not very big when it comes to package management.
      - Xylakant 4y ago
        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.
      - aflag 4y ago
        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.
        Brian_K_White 4y ago
        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.
  - Xylakant 4y ago
    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.
    - jacquesm 4y ago
      You could work with a whitelist or a build environment that is sandboxed somehow.
      - Xylakant 4y ago
        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.
    - smsm42 4y ago
      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.
      - Xylakant 4y ago
        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.
- smsm42 4y ago
  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.
notduncansmith 4y ago
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 https://en.wikipedia.org/wiki/Zero_trust_security_model [1] https://beyondcorp.com https://beyondcorp.com
- kristjansson 4y ago
  Their paper is probably also a useful cite here https://research.google/pubs/pub43231/ https://research.google/pubs/pub43231/
amscanne 4y ago
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.
shdwband 4y ago
[flagged]
UncleMeat 4y ago
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.
dang 4y ago
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 https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.

mnd999 4y ago

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.

ajross 4y ago
> 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.
- charcircuit 4y ago
  Most bug bounties against remote systems are criminal.
- deleted 4y ago
  [deleted]
- scubbo 4y ago
  Can you describe a credible submission to a bug bounty that isn't "100% isomorphic to extortion"?
  - ajross 4y ago
    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!
- mannykannot 4y ago
  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.

Too 4y ago

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.