Interesting discussion here about the possible implication of MS’s recent master key hack on GitHub’s security. Speculation that any repo on Github could now be compromised too, including nixpkgs.
Any thoughts on this?
The speculation would be a lot easier to take seriously if (1) there was a concise summary, rather than scrolling through toots to find a sprawlingly long blog post with tons of unrelated information, (2) there was any actual elaboration of what the supposed compromise of nixpkgs is, would be, etc. Naive modification of history would be caught, I suspect, immediately. Modified tarballs would be noticed, similarly quickly.
I guess an would-be inside-attacker could be rewriting PR merge commits, on the fly? But again, I have a hard time believing that wouldn’t be noticed as well.
I enjoy a good theoretical conspiracy, but they’re a lot more fun to consider and pick apart when they’re specific.
2 Likes
If the source code in the git tree get tampered, it would be easily spotted as each commit depends on its parent, you can’t modify the history and get people to update without issues. An attacker could potentially add new commits though, but it should also be easily spotted.
However, figuring if every PR is sane, it would be really hard to figure.
Pinned nixpkgs versions in building aren’t affected because the checksum is stored along with the url, so existing tarballs would trigger an issue if they were tampered with.
Same issue as the history, you may have a hard time trusting any new tarball generated if you can’t trust your platform.
3 Likes
OK, as I understand it. Confidence is my personal confidence after searching and rereading a bit of reporting.
-
MS … lost exclusivity of access to auth token signing key. This means that for multiple services the attacker can forge access token as an arbitrary user. Confidence: very high.
-
It definitely covers Azure/Outlook/Exchange/OneDrive/etc. accounts, not sure whether GitHub has been 100% integrated on this (and below 100% has a good chance to mean separate keys?). But: MS seems to avoid the direct listing of what is affected and what is not, so possible GitHub is under attack, too. Confidence in the list of affected services: high on inclusion of email accounts, low on everything else.
ETA: I am not making any claims at all about the duration of attackers having or having had access.
-
A lot of GitHub merges for Nixpkgs are done via the web workflow, i.e. we do not have any natural local records to compare against. Confidence: very high.
-
The way to do the attack could probably be a merge via faked access token for some mass-merging committer. While these people do review what they genuinely merge, asking them whether the list of things merged by them is correct won’t yield a high-confidence answer. Everyone just pulls from time to time, probably not checking if they merged at weird time (and an advanced attacker can time the merges for a merge spree). Confidence: quite high.
-
It’s true that disruptive changes to high-rev-dep packages will probably get looked at. But you can probably land a pretty central CVE «fix» with a «cleaned-up» patch that misses one corner case now. Confidence: quite high.
-
The effort to do this in a proper way is non-trivial even after having the key and even after deciding that revealing GitHub forging ability is fine. The masking tactics is probably the same as when planting an own asset as a committer via doing some human-easy build-review-grinding work with the benefit of a nice build server, though. Confidence: medium.
10 Likes