Yakulu has left #nixos-security ["Disconnected: closed"]
Yakulu has joined #nixos-security
pie_ has quit [Ping timeout: 250 seconds]
pie_ has joined #nixos-security
<tilpner>
Hey!
<tilpner>
If you had push rights to nixpkgs and wanted cause the most harm while staying undetected for a good while, what would you do?
<tilpner>
*wanted to cause
<tilpner>
- Reverting a commit, claiming it breaks the package, might reintroduce a patched vulnerability
<tilpner>
- Adding a patch with fetchPatch (as done legitimately in various place) to introduce a backdoro
<tilpner>
I have those two, any ideas that are more sneaky?
<tilpner>
(Don't worry, I don't have push rights)
<xorAxAx>
I would modify nix to introduce backdoors into nixpkgs
pie_ has quit [Ping timeout: 250 seconds]
<tilpner>
No, you don't have push access to Nix
<tilpner>
Just nixpkgs. Unless you meant you were going to patch the nix source from nixpkgs
<simpson>
tilpner: Find out what wastes Hydra build times the most while being hardest to measure, probably by idling in #nixos-dev for a few months and listening to maintainer gripes. Look for patterns in which packages cause the most problems. Go out to the problematic packages' communities, examine their techniques.
<simpson>
Finally, write a PR of minimal size which introduces as many problematic packages as possible, and use push rights to ram it through.
pie_ has joined #nixos-security
<tilpner>
simpson: Why even bother with the PR?
<tilpner>
Oh, send the PR on a new account?
<simpson>
tilpner: No, send the PR on my own account, and use plausible deniability to deny that there are problems with the packages I'm introducing. I'll say that I use them, that others have asked for them, that it's easier to package all of them then just some, etc.
<simpson>
After all, I'd like to stay undetected, even if the PR's rejected, right?
<tilpner>
That is a good answer, and it does a lot of damage
<tilpner>
But it's more sabotage of the project than an attack on the users, and it's longer to explain :c
<simpson>
Well, we can find a way to turn this into a user-oriented attack. We don't freeze ISOs or other release media anymore, right? There's a problem in distros that only roll their release images once, where sometimes a new package can sneak onto the ISO right before release, and then the new package turns out to be insecure/faulty/etc. a few weeks later, requiring a new release.
<simpson>
It's never been clear whether this is a practical avenue of attack, since the only time that I actually see completely fresh release ISOs being used is at installfests. (Remember installfests?)
<simpson>
And installfest newbies usually get automatic updates, which trivially defeat the entire scheme. Rolling releases are powerful.
<tilpner>
Oh no, that's another sort of terrifying
<tilpner>
Malicious helpers during an installfest can do anything, and nixpkgs can't do anything about it
<simpson>
tilpner: I guess that we should back up a little. xorAxAx and I clearly have differing assumptions about auditing; they assume that git commits typically pass in silence, while I assume that every commit is audited. The truth's somewhere in-between, I guess?
<tilpner>
simpson: I don't actually know. I sometimes see committers pushing directly instead of going through a PR
<tilpner>
Who audits those commits?
<tilpner>
Yes, they're announced on IRC, but no, that's no thorough audit, and it'd be a very late one too
<simpson>
I'm not sure. They show up in IRC, and I assume that people who work directly on the Nix tree (Eelco in particular) will notice if their upstream git branch has changed from their local tree.
<tilpner>
That's an assumption I challenge until I hear otherwise
<xorAxAx>
tilpner: ah, ok
<tilpner>
I don't know eelco very well, so he very well might
<tilpner>
But I don't think it's realistic for a few people to review all changes to master after they're already merged
<simpson>
tilpner: Okay, I think I see what you're getting at. Do we still have any fixed-output Truetype fonts? Truetype has embedded bytecode, so an exploit in Freetype, even one that is only a statistical weakening, could be snuck into a font in a way that's hard to detect since it won't rebuild the rest of the tree.
<simpson>
In general, I'm thinking of things that don't cause much rebuilding, if we're trying to be sneaky. A victim in this threat model is going to be unsuspecting, and a large package delta is suspicious.
<simpson>
OTOH how many of us let our eyes just glaze over if there's more than like 30 packages in a delta~
<tilpner>
Are they?
<tilpner>
Indeed, I just accept a low-level thing changed after I update
<tilpner>
And as update intervals grow larger, it's no longer obvious what should be re-downloaded
<tilpner>
Sometimes weeks pass between updates here
<tilpner>
simpson: Context: Motivation section of RFC to deactivate inactive committer rights
<simpson>
tilpner: Aha. Yeah, hard to come up with anything better than "Yes, obviously."
<simpson>
POLA for POLA's sake.
<tilpner>
Well, there are people who haven't committed to nixpkgs in 4 years who still have push rights
<tilpner>
So maybe not obvious enough
<simpson>
No, just not automatic enough. Blame processes, not people.
<tilpner>
Yes, sorry
justanotheruser has quit [Ping timeout: 245 seconds]
pie_ has quit [Ping timeout: 250 seconds]
justanotheruser has joined #nixos-security
pie_ has joined #nixos-security
pie_ has quit [Ping timeout: 250 seconds]
pie_ has joined #nixos-security
pie_ has quit [Ping timeout: 250 seconds]
pie_ has joined #nixos-security
justanotheruser has quit [Ping timeout: 244 seconds]