open source and code review

Posted Nov 11, 2024 20:01 UTC (Mon) by ballombe (subscriber, #9523)
Parent article: The top open-source security events in 2024

The whole open source methodology is predicated on code review.
The detection of the xz backdoor was an effect of the open source methodology and cannot be dismissed as an artifact, so equating it with the crowstrike event is not entirely fair.
How much one is able to reduce a risk is a measure of success.

open source and code review

Posted Nov 11, 2024 22:19 UTC (Mon) by barryascott (subscriber, #80640) [Link] (1 responses)

Code review did not find the xz vuln, it was the curiosity of a developer, Andres Freund, seeing strange test results when working with Postgresql that unearthed the problem.

open source and code review

Posted Nov 12, 2024 13:57 UTC (Tue) by LtWorf (subscriber, #124958) [Link]

And his curiosity could be satisfied with full access to the sources.

open source and code review

Posted Nov 12, 2024 6:07 UTC (Tue) by josh (subscriber, #17465) [Link] (1 responses)

I think the xz backdoor was an example of what code review *doesn't* easily catch, and a demonstration that code which is resistant to code review should be presumptively rejected by default. Checking in autogenerated files, checking in binaries, having bits that can't be reproduced on non-developer systems, anything that thwarts code review shouldn't fly.

It was also an especially painful demonstration of https://xkcd.com/2347/ and what happens when single-point-of-failure projects get handed off to new maintainers, or pressured to get handed off to new maintainers.

open source and code review

Posted Nov 12, 2024 12:20 UTC (Tue) by pizza (subscriber, #46) [Link]

> I think the xz backdoor was an example of what code review *doesn't* easily catch

As the saying goes, it takes two to tango.

The problem with xz was that that the one supposed to be reviewing contributions (ie the only active maintainer) was actively malicious, and there was nobody else willing/able to perform meaningful reviews of that maintainer's contributions.

> Checking in autogenerated files, checking in binaries, having bits that can't be reproduced on non-developer systems, anything that thwarts code review shouldn't fly.

They didn't check in autogenerated files; in this case the dodgy configure script was only in the release tarball, not the public repo. Meanwhile, the binary file was flagged as a defective file used in regression testing, something quite common for test suites, and it is the overwhelming norm for release tarballs to contain generated configure/build scripts versus what is in the repositories. It also takes "non-developers" to determine that things can't be reproduced on "non-developer systems".

Tl;dr: Calls for "maintainer diligence" are meaningless in the face of actively malicious maintainers.