3 ms·

I don't quite understand how this is working tbh. I looked at one of the affected repos, ironically named "reworm". The malicious code was introduced in this c

by nstart 7mo ago

I don't quite understand how this is working tbh. I looked at one of the affected repos, ironically named "reworm". The malicious code was introduced in this commit - https://github.com/pedronauck/reworm/commit/d50cd8c8966893c6269153a3c093c801fd62ba16 https://github.com/pedronauck/reworm/commit/d50cd8c8966893c6... It says coauthored by dependabot and refers to a PR opened in 2020 (https://github.com/pedronauck/reworm/pull/28 https://github.com/pedronauck/reworm/pull/28). That PR itself was merged in 2020 here - https://github.com/pedronauck/reworm/commit/df8c1803c519f599c3b61abd6613c0f98ab44fa4 https://github.com/pedronauck/reworm/commit/df8c1803c519f599... But the commit with the worm (d50cd8c), re-introduces the same change from df8c180 to the file `yarn.lock`. And when you look at the history of yarn.lock inside of github, all references to the original version bump (df8c180) are gone...? In fact if you look at the overall commit history, the clean df8c180 commit does not exist. I'm struggling to understand what kind of shenanigans happened here exactly.

RVuRnvbM2e 7mo ago
Someone has maintainer/admin access to the repository and has force-pushed to master overwriting the git history. Notice that the original commit is verified: https://github.com/pedronauck/reworm/commit/df8c1803c519f599c3b61abd6613c0f98ab44fa4 https://github.com/pedronauck/reworm/commit/df8c1803c519f599... While the malicious one is not: https://github.com/pedronauck/reworm/commit/d50cd8c8966893c6269153a3c093c801fd62ba16 https://github.com/pedronauck/reworm/commit/d50cd8c8966893c6...
- globular-toast 7mo ago
  This reveals a deeper flaw in the whole git/npm pipeline (would apply to other systems like PyPI etc, not npm exclusively). These systems should operate on a "pull" model, not a push. The system should have rejected a build that wasn't derived from the latest in its repository. It would be quite easy in concept to set up one's own system to pull every source on npm and alert when the upstream has deviated.
  - redman25 7mo ago
    So someone is debugging something with git bisect and stumbles on the old commit and gets pwned. Maybe that's why they force killed it? To avoid people going back in history and stumbling on it.
jibal 7mo ago
The malicious code was added to package.json, not yarn.lock
- nstart 7mo ago
  Yup. That's correct. And I understand that. I was looking at the changes to yarn.lock that got reintroduced. I couldn't figure out what was happening. It turns out that not only was it force pushed, but GitHub also retains the old commit information even if it's been "deleted". I still don't quite understand what GitHub is doing to allow someone to say that dependabot coauthored a spoofed commit. This isn't the commit message itself I'm talking about. It's the GitHub interface that officially recognizes this as a dependabot co authored commit. My hunch is that the malicious author squashed two commits, the original good commit to yarn.lock and a malicious change to package.json, and that somehow maintains the dependabot authorship instead of reassigning it fully to the squash-er.

by nstart 7mo ago

RVuRnvbM2e 7mo ago

Someone has maintainer/admin access to the repository and has force-pushed to master overwriting the git history. Notice that the original commit is verified: https://github.com/pedronauck/reworm/commit/df8c1803c519f599c3b61abd6613c0f98ab44fa4 https://github.com/pedronauck/reworm/commit/df8c1803c519f599... While the malicious one is not: https://github.com/pedronauck/reworm/commit/d50cd8c8966893c6269153a3c093c801fd62ba16 https://github.com/pedronauck/reworm/commit/d50cd8c8966893c6...

globular-toast 7mo ago
This reveals a deeper flaw in the whole git/npm pipeline (would apply to other systems like PyPI etc, not npm exclusively). These systems should operate on a "pull" model, not a push. The system should have rejected a build that wasn't derived from the latest in its repository. It would be quite easy in concept to set up one's own system to pull every source on npm and alert when the upstream has deviated.
- redman25 7mo ago
  So someone is debugging something with git bisect and stumbles on the old commit and gets pwned. Maybe that's why they force killed it? To avoid people going back in history and stumbling on it.

jibal 7mo ago

The malicious code was added to package.json, not yarn.lock

nstart 7mo ago
Yup. That's correct. And I understand that. I was looking at the changes to yarn.lock that got reintroduced. I couldn't figure out what was happening. It turns out that not only was it force pushed, but GitHub also retains the old commit information even if it's been "deleted". I still don't quite understand what GitHub is doing to allow someone to say that dependabot coauthored a spoofed commit. This isn't the commit message itself I'm talking about. It's the GitHub interface that officially recognizes this as a dependabot co authored commit. My hunch is that the malicious author squashed two commits, the original good commit to yarn.lock and a malicious change to package.json, and that somehow maintains the dependabot authorship instead of reassigning it fully to the squash-er.