Abusing Git branch names to compromise a PyPI package | Hacker News Reader

Abusing Git branch names to compromise a PyPI package

lwn.net

32 pointsstevekemp17 comments

Ultralytics AI model hijacked to infect thousands with cryptominer (https://www.bleepingcomputer.com/news/security/ultralytics-a...) - discussed 2 days ago: https://news.ycombinator.com/item?id=42351722

Discrepancy between what's in GitHub and what's been published to PyPI (https://github.com/ultralytics/ultralytics/issues/18027) - https://news.ycombinator.com/item?id=42337548

That GitHub thread is an embodiment of everything that is wrong with "open" source these days:

First they lock the conversation as off-topic (?!), the rest is meandering, ultra-verbose business speak that evades the point, which simply is: You fucked up.

The CoC people in the Python ecosystem have turned everything into a playground for incompetent people who protect each other by censorship and reams of verbose platitudes. Companies like Google have noticed this.

Why would Google have noticed when they vendor everything, including Python packages, usually rewriting them fairly intensively to work better with bazel? They literally don't care about squabbling over GH issues or malicious branch names.

when I worked at Google, the packages were so late behind the newer updates, when they were available at all. I wonder if that's still the case

Probably. That was always described as an intentional tradeoff when vendoring, and not necessarily even a negative one.

"turned everything into a playground" would imply broader issues, of which packaging is just one manifestation. Obviously Google has noticed, because they fired the Python team.

They fired the Python team in a round of rolling layoffs on nearly every team, immediately replaced them with a lower cost-of-living-adjusted team, and left the infrastructure basically identical.

The fact that they were all fired is definitely evidence in favor of the claim that there were problems Google noticed, but combined with the rest of the picture I'm not sure that decision supports that hypothesis.

the same happens to every other project that gets infested by the CoC people

at that point just move on and find another library/tool/language/OS kernel :(

This is such an odd take. I've never run into an issue with contributing to projects with a code of conduct. I find people's weird obsession over this to be confusing, really.

Don't get me wrong, I'm sure you'll be able to find individual examples of issues that have come up, but it doesn't seem like enough of a pattern to completely abandon projects simply because they've adopted one. It seems more like people picking an ideological battle than anything else.

it's not the document itself, it's more a project deciding that technical excellence is no longer the number one priority

inevitably the priority of keeping everyone "happy" at a facile level leads to poor technical decisions being made (see: modern python)

not to mention the also inevitable weaponisation of the document as a political tool to defeat one's enemies

That interaction looks fine to me. It's just their automated bot response for newcomers, which they use with similar wording across all issues. While the thread was initially locked, it was probably a false positive and quickly reopened by a human.

"to compromise a GitHub repository" would be a better title. The vulnerability here is with GitHub Actions combined with improper CI configuration. PyPI has nothing to do with this, really (other than being the site where this vulnerable repository's releases are uploaded).

Was this because a shell script was using interpolation to add branch name to a shell command? Maybe we should start getting rid of string substitution-based shells?

Correct. The GitHub Action was doing

`git pull origin ${{ github.head_ref || github.ref }}`

In the pull_request_target action, $github.ref is the name of the branch, which in this case included a curl request for a shell script, a pipe character, and bash.

I highly recommend the comments, particularly this from excors: https://lwn.net/Articles/1001309/

I am far from an expert on CI / GitHub, so when I saw this attack I thought "sure I guess that could happen" but was pretty baffled as to how beyond some hand-waving about escape characters and the dangers of mixing data and code.

[dupe] https://news.ycombinator.com/item?id=42351722

How could this happen? We're storing deploy credentials in GitHub, and configure fully automated deploy pipelines using YAML and Shell. Escaping 101. xD

https://xkcd.com/1638/

Reply on news.ycombinator.com