A backdoor in xz

Posted Apr 1, 2024 12:48 UTC (Mon) by pizza (subscriber, #46)
In reply to: A backdoor in xz by himi
Parent article: A backdoor in xz

> This is mostly what I was thinking of - have a human-readable language designed to specify the binary formats, and use that to generate the test data.

So... you have this human-readable language generate a malicious file that contains the payload for an exploit. What have you gained here?

The problem is that the binary data is "hostile", not "how the binary data was generated".

A backdoor in xz

Posted Apr 2, 2024 3:16 UTC (Tue) by himi (subscriber, #340) [Link]

If we can't simply trust that the contents of the repository aren't malicious, we need to be able to independently verify that they're not malicious. The point of a human-readable specification of the binary data is to try and make it possible for a human to read it and say "the binary version of this spec won't be malicious". Is that possible? In the general case I don't think so, but I'm pretty sure there are going to be a good number of cases where it /is/ possible, for someone with the requisite knowledge of the format. I'm suggesting that where it's possible, it might be worth trying to do, to mitigate against at least some of the risks posed by malicious binary blobs in source repositories.

As I've said, even if this idea might work in some cases I suspect it wouldn't be viable for xz or similar, simply because of the nature of compression algorithms. But if you can make "has undefined binary files as part of the test data set" into a code smell that gets people to take a closer look then you're raising the bar for sneaking a malicious payload into a repository.