3 ms·

Would make stuff like this harder to pull off: https://en.wikipedia.org/wiki/XZ_Utils_backdoor https://en.wikipedia.org/wiki/XZ_Utils_backdoor

nindalf 2y ago
Are you sure? If I'm understanding correctly, the malicious code was introduced as part of the test code, so no matter who compiled it, they'd get a binary with the same (malicious) functionality. Heck, it might even have been reproducibly malicious. The real crazy part was that it was modifying the functionality of sshd at runtime, allowing the attacker to log into any system. Reproducibility of either sshd or xz wouldn't have stopped this attack. That's my reading of https://research.swtch.com/xz-script https://research.swtch.com/xz-script.
- solarkraft 2y ago
  I tend to agree. The exploit was (by detour) committed to the source.
  - ramses0 2y ago
    Technically, interestingly, if `bazel` were used as the build tool, it would avoid the straightforward ability to cross-contaminate the build executable with the test code... Yeah, `bazel run test:...` would have access to the test files, but `bazel build xz:executable` would not (by default) be able to pull in extra shenanigans from the test files (and I think there's generally linting and formatting rules required by default with `BUILD.bazel` files, reducing another sneak-vectors)
kpcyrd 2y ago
It unfortunately doesn't help in cases like this. Reproducible Builds gives you a trusted path from source to binary, but it doesn't help with backdoors in the source code/build instructions. For that we'd need some sort of source code reviewing effort like https://github.com/crev-dev/cargo-crev https://github.com/crev-dev/cargo-crev implements. I've started whatsrc.org to keep track of the source code inputs we're putting into our computers (that would benefit from reviews), but the conclusion is also somewhat "it's too much".

nindalf 2y ago

Are you sure? If I'm understanding correctly, the malicious code was introduced as part of the test code, so no matter who compiled it, they'd get a binary with the same (malicious) functionality. Heck, it might even have been reproducibly malicious. The real crazy part was that it was modifying the functionality of sshd at runtime, allowing the attacker to log into any system. Reproducibility of either sshd or xz wouldn't have stopped this attack. That's my reading of https://research.swtch.com/xz-script https://research.swtch.com/xz-script.

solarkraft 2y ago
I tend to agree. The exploit was (by detour) committed to the source.
- ramses0 2y ago
  Technically, interestingly, if `bazel` were used as the build tool, it would avoid the straightforward ability to cross-contaminate the build executable with the test code... Yeah, `bazel run test:...` would have access to the test files, but `bazel build xz:executable` would not (by default) be able to pull in extra shenanigans from the test files (and I think there's generally linting and formatting rules required by default with `BUILD.bazel` files, reducing another sneak-vectors)

kpcyrd 2y ago

It unfortunately doesn't help in cases like this. Reproducible Builds gives you a trusted path from source to binary, but it doesn't help with backdoors in the source code/build instructions. For that we'd need some sort of source code reviewing effort like https://github.com/crev-dev/cargo-crev https://github.com/crev-dev/cargo-crev implements. I've started whatsrc.org to keep track of the source code inputs we're putting into our computers (that would benefit from reviews), but the conclusion is also somewhat "it's too much".