XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."

Re:XZ backdoor: "It's RCE, not auth bypass, and gated/unrepl... by XorNot on Saturday March 30, 2024 @07:53PM (#39879842)

If you think about it this is a data-providence problem though. The exploit was hidden in "test" code which gets included in release code by compiler flags.

Now, if there was a proper chain of accountability for data, then this wouldn't have been possible to hide the way it is - any amount of pre-processing resulting in the release tarball including derived products of "test" files would be suspicious.

The problem is we don't actually track data providence like this - no build system does. The most we do is <git hash in> -> <some deterministic bits out>. But we don't include the human readable data which explains how that transform happens at enough levels.

[ Parent | on HN ]

Re:XZ backdoor: "It's RCE, not auth bypass, and gated/unrepl... by paulmd on Sunday March 31, 2024 @06:09AM (#39882919)

You don’t need to go to that extent even - simply properly segregating test resources from dist resources would have prevented this, and that’s something Java has been doing for 20 years.

It’s not sufficient against a determined attacker, but it does demonstrate just how unserious the C world is about their build engineering.

I literally can’t think of a single time in 15 years of work that I’ve ever seen a reason for a dist build to need test resources. That’s at best a bug - if it’s a dist resource it goes in the dist resources, not test. And if the tooling doesn’t do a good job of making that mistake difficult… it’s bad tooling.

[ Parent | on HN ]