461–470 of 482 posts
Earlier quoted context omitted.
I was wondering if that would be released also. I hope so but wouldn't blame them if they decide not to.
I wouldn't blame then if they've thrown all their computers into the sea, changed their name, and taken upon a job building timber furniture...
Earlier quoted context omitted.
Ultimately you're going to have to be adept at stuff like the Underhanded C Contest to spot this kind of thing in any Turing-complete language, so the idea of auditing the source is unreliable at worst. So I'd take another page from the Java/Maven ecosystem and require hashed+signed binaries, with the possible addition of requiring builds to be performed on a trusted remote host so that at least we can verify the bin…
> to spot this kind of thing in any Turing-complete language I’m not sure I follow. The bar for passing review and audits is “people can understand it”, at least to the point of preventing smuggling in a custom public keys and other shenanigans – as opposed to “all valid programs in the language”. While I agree Turing-completeness opens up undeniable complexity, it’s the best we got. And there are huge variations in…
Earlier quoted context omitted.
It's easier to hide nastiness in a binary than it is in source. And indeed this XZ hack too relied on multiple obfuscated binary blobs. The hash helps because it makes it a little harder to hide things like this. It's not a silver bullet, but it would have in this specific instance made it harder to hide that malicious m4/build-to-host.m4 in the tarball - after all, had the attacker done that despite publishing a has…
"slightly harder" isn't enough. That's what I'm saying that people are not accepting. The days of 3rd party libraries simply being trusted because they're open source are slowly coming to an end. the problem is not unreproducible builds, the problem is that we implicitly trust source code found online. Projects relying on 100s of 3rd party libraries are a major problem, and no one seems to care. They like it when the…
I guess that Lasse Collin will have more mental health issues after all of this :-) Do we know who really is Jia Tan? Any photo of him? The email addresses he has been using? His location?
What makes you think they are an actual person?
2022-06-08: Lasse Collin said that he had worked off-list a bit with Jia Tan.
I think that "off-list" means not on the xz mailing list, maybe over the personal email/phone/voice app. That's why I thought that Jia Tan was a real person
Earlier quoted context omitted.
Actually, this xz-utils was a sort of reproducible build issue. But the twist it is wasn't the binary not built reproducibly. It was the tar ball. The natural assumption is it just reflected the public git repository. It didn't. Debian's response is looking to be mandating the source must come from the git repository, not a tar ball. And it will be done using a script. And the script must produce the same output ever…
So if something is hidden in the source, a reproducible build will give you the confidence to believe that the source is fully vetted and clean. I see what you’re saying, but I don’t buy that reproducible builds actually solve anything, especially long term. As this whole xz thing has shown us, lots of things fly under the radar if the circumstances are right. This kind of thing will absolutely happen again. In the f…
A window that can be smashed in is still a vulnerability, so there is no value in people locking their front doors.
Earlier quoted context omitted.
I don't think it's acceptable to create a subprocess for what's effectively a library function call because it comes from a dependency. The problem is the design of rtld and the dynamic linking model, where one shared library can detect and hijack the function calls of another by using the auditing features of rtld. Hardened environments already forbid LD_PRELOAD for injection attacks like this, but miss audit hooks.…
I don't agree -- process isolation is a simple, effective, and traditional mechanism. It has downsides (e.g. parsing and serializing), but they don't apply here. Many mitigations work at the process level, like ASLR, cgroups, and more. There's a reason that Chrome doesn't allow parsing and rendering in the same process: https://www.chromium.org/developers/design-documents/multi-p... Something like the rule of 2 shoul…
Having written multi-process programs used for this purpose, I disagree that it's simple or traditional for the purposes of hardening against supply chain attacks in shared libraries. Only at the most naive level is it appropriate.
And on top of that, it would not have prevented the backdoor. It would only have changed the mechanism used to invoke it.