This is a scary one ... CVE-2024-3094

[radiolistener]

Binary blobs *purely for testing purposes* are "fine", the issue is with whatever code uses them. Binary blobs should be used *only* for testing known good outputs vs. actual outputs and the code for testing should be as simple and straightforward as possible.

Binary blob may exploit some code vulnerability, like stack overflow to execute some raw code from the binary blob... 
And the code which uses it will be clean...
So, I don't think this is fine... 

[golden_labels]

Executable blobs are something I despise. But data blobs? Ignoring testing for a moment: you need image, audio, game-specific data for programs. One might argue their place is not in the main repository. But in practice this is a common situation. And for many tests data, including invalid data, is a requirement. Generating it at test time from code is not a solution: the code becomes opaque for any more complicated case and it’s equally trivial to hide malicious payload in it. Or, under a pretense of dynamically generating invalid cases from an trusted blob, cut and stich fragments to get the desired result.

I wouldn’t focus on blob’s presence. This part of the attack was the first to be detected too, early enough to not cause harm. Focus more on what led to it. Careful, long-term execution. Building reputation. Social engineering, including sockpuppeting, brutally exploiting health situation of Lasse Collin. Having commits accepted by two of top-5 technology companies, and nobody noticing anything.

[SiliconWizard]

Binary data that is not executable can't execute anything on its own. If it leads to code execution, this is by exploiting some other code that reads said data and has a bug. (Or does so intentionally.)
So when using binary data for testing purposes, you basically have 2 cases:

- Known good outputs: the tests execute the tested code under various known conditions and its binary output is compared to the "binary blob" - usually with the simplest tool possible, such as 'diff', which has no exploit that I know of (but not claiming it has none, who knows, and I didn't fully check that). In the case of a compression library, for instance, you'd compare the output of the compression for known inputs to the expected binary output. End of the story.

- Inputs: similarly, you may need to test your code with known binary inputs. In the case of a compression library, again, that may be the input data that you want to compress as a test. Binary inputs *may* trigger an exploit in the tested code, if said code has any. But this would happen only while testing, and if it happens at this test stage, that would normally be good news (as long as you can detect it.)

"Unacceptable" uses of binary blobs include: executables, and third-party *code* that may extract nasty code from said blobs (which was the case in the xz affair). But either of these cases are, IMO, obvious issues. (Not saying that they are always obvious to see, although again in the xz case, just properly reviewing the build and test scripts would have shown it quickly.)

But not using any binary data, I don't know how you can if you're testing code that is meant to read or write binary data itself. At some point you need to test it with actual inputs and check that the outputs are what's expected. If you know how to properly test, say again as an example, a compression library without using any binary data, let me know.

[golden_labels]

In this case the blob wasn’t included as something to be executed. It was data for tests. And, if I understand correctly, inclusion binary data for tests is being discussed. Am I wrong?

[madires]

Open Source Security (OpenSSF) and OpenJS Foundations Issue Alert for Social Engineering Takeovers of Open Source Projects: https://openssf.org/blog/2024/04/15/open-source-security-openssf-and-openjs-foundations-issue-alert-for-social-engineering-takeovers-of-open-source-projects/

The recent attempted XZ Utils backdoor (CVE-2024-3094) may not be an isolated incident as evidenced by a similar credible takeover attempt intercepted by the OpenJS Foundation ...