upvote

points

by chrisweekly13 hours ago |
comments
upvoteby jonchurch_10 hours ago|
next
[-]
The compromised action here was using pnpm.

They poisoned the github action cache, which was caching the pnpm store. The chain required pull_request_target on the job to check bundle size, which had cache access and poisoned the main repo’s cache

The malicious package that was publisjed will compromise local machines its installed in via the prepare script, though.

reply
upvoteby ricardobeat3 hours ago|
parent|
next
[-]
Those are two different attack vectors. The exploit they used on Github Actions would work for either npm or pnpm. But the replication part using postinstall scripts, once it is installed on another machine, would be stopped by pnpm.

What I'm curious about is: how can you poison the cache in CI, if the lockfile has an integrity hash for each package?

Did the incoming PR modify pnpm-lock.yaml? If so, that would an obvious thing to disallow in any open-source project and require maintainer oversight.

reply
upvoteby maxloh5 hours ago|
parent|
prev|
next
[-]
I think it was an afterthought in the design. CI cache should be scoped per-user, or at least per-group.

If a workflow run by a maintainer (with access to secrets) can pull a cache tarball uploaded by a random user on GitHub, then it’s a security black hole. More incidents like this are inevitable.

reply
upvoteby corvad8 hours ago|
parent|
prev|
[-]
Yes, but the exploit was with Github Actions not something that pnpm really prevented.
reply
upvoteby fabian2k13 hours ago|
prev|
next
[-]
Once you run your app with the updated dependencies, that code is executed anyway. And root or non-root doesn't matter, the important stuff is available as the user running the application anyway.
reply
upvoteby 10 hours ago|
parent|
[-]
deleted
reply
upvoteby yetanotherjosh12 hours ago|
prev|
[-]
How is this not a Github P0? Can anyone explain?

When I read that, I thought they must be using 'fork' wrong, and actually mean branch on the official repo, as that can't be right!?" Good lord.

reply
upvoteby sheept6 hours ago|
parent|
next
[-]
In some cases, you can also use forks to read commits from private forks[0], but GitHub considers these linked commit networks working as intended.

[0]: https://trufflesecurity.com/blog/anyone-can-access-deleted-a...

reply
upvoteby sozforex4 hours ago|
parent|
[-]
This is a very worthy article. I have an impression that I've read it before 2024, but maybe that was a different article describing the same mess with how github exposes private repos.
reply
upvoteby edelbitter7 hours ago|
parent|
prev|
next
[-]
If git in general would enforce pretending to not know about orphans, it would always need to know what you were meaning to consider the boundary, and/or you would end up waiting for useless duplicate network traffic. The fact that on GitHub, such references are visible irrespective of specified repo is not a bug, its a feature. Its the tools (including but not limited to: GitHub Actions) that cause dangerous misunderstanding in appearing to let you specify something they then never actually enforce.

specified: repo location, slightly-difficult-to-preimage hash

intended meaning: use this hash if and only if it is accessible from the default branch of that repo

actual meaning: use this hash. start looking at this location. I do not care whether it is accessible through that location by accident, by intent of merely its uploader, or by explicit and persisting intent of someone with write access to the location.

reply
upvoteby cedws4 hours ago|
parent|
prev|
next
[-]
Because GitHub only cares about AI.
reply
upvoteby eviks3 hours ago|
parent|
[-]
And maintaining high level of service availability!
reply
upvoteby rvz1 hours ago|
parent|
[-]
With zero down time!
reply
upvoteby ZeWaka12 hours ago|
parent|
prev|
[-]
they probably used the publish token in a pull-request-target workflow or something?
reply
upvoteby ghost_pepper11 hours ago|
parent|
[-]
yes, they used pull_request_target for a benchmarking suite. github has a huge warning saying to never use pull_request_target to run user code, but this is just going to keep happening
reply
upvoteby riknos31410 hours ago|
parent|
next
[-]
> github has a huge warning saying to never use pull_request_target to run user code

This is an area where documentation is necessary but not sufficient. Github needs to add some form of automated screening mechanism to either prevent this usage, or at the very least quickly flag usages that might be dangerous.

reply
upvoteby hombre_fatal5 minutes ago|
parent|
[-]
"pull_request_target" vs "pull_request" is also bad naming. At least give it a dangerous name.
reply
upvoteby qudat8 hours ago|
parent|
prev|
[-]
And a labeling action which requires `pull_request_target`: https://github.com/actions/labeler#create-workflow

These types of features are not worth it and need to be removed from the marketplace.

reply