Free software's not-so-eXZellent adventure

Posted Apr 3, 2024 16:40 UTC (Wed) by draco (subscriber, #1792)
In reply to: Free software's not-so-eXZellent adventure by smurf
Parent article: Free software's not-so-eXZellent adventure

In the XZ backdoor case, the build read from the test artifacts, the tests didn't write to the build

Of course, both should be disallowed

Free software's not-so-eXZellent adventure

Posted Apr 4, 2024 10:36 UTC (Thu) by smurf (subscriber, #17840) [Link] (2 responses)

Well, if the build actively reads test output then it's subverted anyway; reading the test output is then "only" a matter of obfuscation.

Free software's not-so-eXZellent adventure

Posted Apr 4, 2024 18:28 UTC (Thu) by draco (subscriber, #1792) [Link] (1 responses)

No, it read from test *input*. There was no need to run the tests.

Here's a picture: https://cdn.arstechnica.net/wp-content/uploads/2024/04/xz...

Free software's not-so-eXZellent adventure

Posted Apr 5, 2024 9:11 UTC (Fri) by smurf (subscriber, #17840) [Link]

It reads from data that was hidden in / disguised as part of the test suite; the file in question wasn't even used as actual test input AFAICR. That falls squarely into the "subverted anyway" category.

So yes you're right in that in this case the test output didn't actually influence the build. Thus to be safe against "hide an exploit's core in plain sight" attacks we'd have to go a step further and mandate that the builder cannot access its test data, binary or otherwise.