rotopenguin

In the coming weeks, you will know if this attacker recycled any techniques in other attacks. People have furiously ripped this attack apart, and are on the hunt for anything else like it out there. If Jia has other naughty projects out here and didn't make them 100% from scratch, everything is going to get burned.

How do you know there isn't a logic bug that spills server secrets through an uninitialized buffer? How do you know there isn't an enterprise login token signing key that accidentally works for any account in-or-out of that enterprise (hard mode: logging costs more than your org makes all year)? How do you know that your processor doesn't leak information across security contexts? How do you know that your NAS appliance doesn't have a master login?

This was a really, really close one that was averted by two things. A total fucking nerd looked way too hard into a trivial performance problem, and saw something a bit hinky. And, just as importantly, the systemd devs had no idea that anything was going on, but somebody got an itchy feeling about the size of systemd's dependencies and decided to clean it up. This completely blew up the attacker's timetable. Jia Tan had to ship too fast, with code that wasn't quite bulletproof (5.6.0 is what was detected, 5.6.1 would have gotten away with it).

There's hardlink, and then below that there's the COW/dedupe version called "reflink". Two files can point to the same chunks of data (extents), and altering one does not alter the other. Two files can point to just some of the same chunks of data, too. I don't think there is much indicator for when this is happening, besides the free space vs used space accounting looking crazy. If you "compsize" two reflinked files at once, it'll show you the difference.

You can do "zfs style raid things" with btrfs, but there are way too many reports of it ending badly for my tastes. Something-something about "write hole".

compsize will give you an honest overview of what's going on with btrfs.

The more EA breaks their own shitty games, the more powerful Linux becomes

Shaking hands with St. Peter, slipping him a crisp $20: I think everything's all set here, don't you Pete? C'mon, open up those big beautiful pearly gates.

My $0.05 reading of it is that they want to hose down the build servers* and start clean, in case if the attacker escaped the sandboxing there.

* (the computers that compile all of the new packages from source, not web servers that are handing out finished deb binaries to the public.)

I stand corrected. All programs should have access to anything, anywhere, and be linked to liblzma just in case if some arbitrary file is compressed. Thank you for setting me straight.

Any app that can be sandboxed, should. Especially apps that are parsing random data from the internet.

It can then go from a snap to a superior flatpak real quick.