Hacker News Reader

Hacker News

Comment by zb3 | Hacker News Reader

Full thread

zb3

This appears to be a code injection in a PR branch name, not an AI model compromise..

View on HN

The malware was in the pypi package, so anyone doing `pip install ultralytics` would've received the virus.

The injected malware code came from the PR branch name, called by a Github action that was misconfigured.

Yeah, I think the story that's being missed here is that GitHub allows branches named "$(curl...|bash)".

Sounds like something GitHub should be easily able to detect too.

Hopefully that's an exploit path they'll close soon, if they've not done so already.

What/where does code get evaluated from a branch name?

In Github Actions, because their runners use echo commands to print out environment variables and variables that have been declared via inputs, which in return is parsed in the UI.

So technically, all environment variables are unsanitized and this was only the first problem in a list of bugs. This bug specifically used the "pull_request" event/action because it is automatically executed without any chance of stopping it, and was using details exposed via the pull requests head.ref.

Next up: git usernames and emails that use shellcode injection names, because github probably won't introduce sanitization to all variables/inputs now.

This is a prime example why you should never ever use a shell to log arbitrary data.

Github should not disallow/filter branch names. Developers should write (and be be given the tools to) workflows that do not allow command injection.

GitHub could disallow/filter branch names. Developers will not write (and be be given the tools to) workflows that do not allow command injection.

Do you have the same reasoning for SQL/XXS injection? Should developers not write code that is resistant to SQL/XXS injection and instead rely on something like a WAF?

These protections (WAF for SQL/XSS, branch names for this) will never be enough. The code/logic must be secure, any additional layer is not enough since the actual target must be secured.

Developers will do it if its necessary, and it is. These situations are just proving it is necessary.

the garbage that is yaml "builds" is essentially impossible to secure

untyped strings, untyped strings everywhere

and they're directly executed, with untrusted user input templated in, with full release privileges

the entire thing is insane

to think pypa deprecated pgp offline signing for this...

Why not both? Git itself checks and sanitizes branch names, and GitHub should arguably match that behavior. I don't think anyone would object to safer workflows and related tooling instead of being told "here, have some bash inside YAML, now be careful!"

Of course I agree that github should follow the git spec for branch names. I meant that I don't think github should impose any additional restrictions on branch names.

The yolo models are “dumb” black box object detectors, it’s a supply chain attack, the model itself was very likely never touched

in parlance this is fine because weights of a model is useless without the wrapper code around it. ignoring the monorepo bs a lot of ai companies are pushing (like hugging face also), this is not as misleading as calling open-weight models as open-source.

Reply on news.ycombinator.com