101–110 of 322 posts
On an unrelated note, this malware team has assembled a great dataset for training AIs on identifying security problems. Every commit has some security problem, and the open source community will be going through and identifying them. (Thanks, maintainers, for the cleanup work; definitely not fun!)
Earlier quoted context omitted.
Because a deliberate vulnerability is much easier to hide than actual malicious content. One could probably sneak a buffer overflow or use-after-free into a C project they maintain without being noticed. Actually shipping a trojan is much harder, as observed with the xz-to-sshd backdoor.
Ah, so the next stage would have been to add a "bug" in xz that would trigger during the supposedly sandboxed execution, when presented with certain input files. Clever.
Earlier quoted context omitted.
This has plausible deniability on it. There's better ways to hide by swapping in Unicode lookalike characters. Some of them even pixel match depending on the font. Maybe I'm out of the loop but is intentionality settled here?
the period right there on the left edge? if I saw that in a patch I'd be through the roof, that looks completely intentional
Geez, his last commit is making security reports worse: https://git.tukaani.org/?p=xz.git;a=commitdiff;h=af071ef7702...
Earlier quoted context omitted.
Ah yes but thanks to C being cursed due to includes and macros this is harder to do
Huh, the code with a dot is not legal C. It is CMake issue that the test breaks here.
Earlier quoted context omitted.
This has plausible deniability on it. There's better ways to hide by swapping in Unicode lookalike characters. Some of them even pixel match depending on the font. Maybe I'm out of the loop but is intentionality settled here?
the period right there on the left edge? if I saw that in a patch I'd be through the roof, that looks completely intentional
:wq!
Earlier quoted context omitted.
Because nobody’s really paying attention. “LGTM!”
Generally yes, but ripping all conditions out of SECURITY.md should at least raise an eyebrow?
If you have commit access to it, and nobody is there to see, nothing stops you.
Earlier quoted context omitted.
This has plausible deniability on it. There's better ways to hide by swapping in Unicode lookalike characters. Some of them even pixel match depending on the font. Maybe I'm out of the loop but is intentionality settled here?
Unicode lookalikes would be detected by IDEs and other tools. There would be plausible deniability in a different situation, but this is the same author who implemented the backdoor and several similar changes that disable security features. I don't think the benefit of doubt is deserved here.
How can we ensure say, that Microsoft doesn't pay someone to throw a wrench in libre office development or Adobe to sabotage Gimp?
There's lots of deception strategies for bad faith actors and given the paucity of people who actually do the work, it's really really hard to be picky.
Especially with the complexity of library dependencies. Defect-at-a-distance may actually be a common strategy and this is the first that was caught