4 ms·

Deterministic/repeatable builds can help with issues like this: once the binaries exist from checksummed code repository and are hashed, the tests can do whate

Deterministic/repeatable builds can help with issues like this: once the binaries exist from checksummed code repository and are hashed, the tests can do whatever they want but if the final binaries change from the recorded hashes they shouldn't get packaged. This is in general a problem with traditional permission models. Pure capabilities would never leave binaries writable by anything other than the compiler/linker, shrinking the attack surface.

edflsafoiewq 3y ago
Running the tests does not modify the binary. The build script was modified to create a malicious .o file which was linked into the final binary by the linker as normal. Tests were only involved in that the malicious .o was hidden inside binary test files.
- paulmd 3y ago
  letting dist builds be linked against test resources is a design defect to begin with, and the fact that this is easy/trivial/widely-accepted is a general indication of the engineering culture problems around C. Nobody in Java word is linking against test resources in prod, and a sanely designed build system should in fact make this extremely difficult. That shit went away in the maven/gradle days - which is for a reason, ant is basically makefiles for Java, gradle/maven are a build system not a pile of scripts. And that transition happened 20 years ago! If you can’t even prevent a test resource being linked into a final build you are not serious. I don’t care about legacy whatever, that’s an obvious baseline metric for security culture / build engineering. Maybe not “prevent” but like, tooling should absolutely make it blindingly obvious that you’re violating best-practices by disabling scoping rules or including unusual source/resource roots, etc. C has never moved past the 1970 mindset of build being a pile of scripts with a superstructure bolted on. Just like Ant. Even the attempts to fix C’s build are just better ways to programmatically generate better bash scripts to keep you going off the rails.
  - malkia 3y ago
    Good point, bot sure if enforced there, but systems like bazel (buck?) and others have ways to mark build nodes as "testonl"

edflsafoiewq 3y ago

Running the tests does not modify the binary. The build script was modified to create a malicious .o file which was linked into the final binary by the linker as normal. Tests were only involved in that the malicious .o was hidden inside binary test files.

paulmd 3y ago
letting dist builds be linked against test resources is a design defect to begin with, and the fact that this is easy/trivial/widely-accepted is a general indication of the engineering culture problems around C. Nobody in Java word is linking against test resources in prod, and a sanely designed build system should in fact make this extremely difficult. That shit went away in the maven/gradle days - which is for a reason, ant is basically makefiles for Java, gradle/maven are a build system not a pile of scripts. And that transition happened 20 years ago! If you can’t even prevent a test resource being linked into a final build you are not serious. I don’t care about legacy whatever, that’s an obvious baseline metric for security culture / build engineering. Maybe not “prevent” but like, tooling should absolutely make it blindingly obvious that you’re violating best-practices by disabling scoping rules or including unusual source/resource roots, etc. C has never moved past the 1970 mindset of build being a pile of scripts with a superstructure bolted on. Just like Ant. Even the attempts to fix C’s build are just better ways to programmatically generate better bash scripts to keep you going off the rails.
- malkia 3y ago
  Good point, bot sure if enforced there, but systems like bazel (buck?) and others have ways to mark build nodes as "testonl"