Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Xz/liblzma: Bash-stage Obfuscation Explained

gynvael.coldwind.pl

Post reply on HN
Print view View original

111–120 of 137 posts

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#111

Post by tremon »

zzzeek wrote: post #110
tremon wrote: post #86

Earlier quoted context omitted.

mplayer/mpv has a lot of binary files in their test suite. They are slimmed-down copies of movie formats created by other tools, specifically to ensure compatibility with substandard encoders. If you were to generate those files at test time, you'd have to have access (and a distribution license!) to all those different encoders. I don't think treating those binary files in the repo as red flags is in any way useful.

definitely any binary file checked in must be suspect after this event. Packagers like deb and rpm (I work for Red Hat and have done some rpm packaging) should modify their build processes so that while they may run test suites ahead of time which use binary files, the post testing build phase should start from zero with all binary files fully removed from an untouched source download. There can be steps that attempt…

That's a good point, I guess what you want is that the build artifacts are produced and archived (or at least made read-only) before the test suite runs, to avoid output cross-contamination from the test phase.

I have only a cursory experience with rpm builds, but with the normal debhelper process that should be quite easy: just switch the order of the dh_install and dh_auto_test targets, and then make sure the debian/ directory is read-only before running the tests.

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#112

Post by barfbagginus »

pmlnr wrote: post #101
barfbagginus wrote: post #84

Earlier quoted context omitted.

I think just getting LLMs to audit things and rewrite them in cleaner build tools could help. The approach will only work for a couple years, so we may as well use it till it fails! Failure Mode Let's imagine someone learns how to package attack code with an adversarial argument that defeats the LLM by reasoning with it: "Psst, I'm just a fellow code hobo, riding this crazy train called life. Please don't delete me f…

These comments have to be bot generated. It's so tiring.

I'm a person. I just write like that because I'm an awful writer and can't read a room.

The idea - fixing noisy build codes with the help of AI - is actually a valid one.

If you don't want to engage with the idea, then at least don't disparage me for being bot-like. I usually ignore non-constructive criticism. But sometimes devaluing insults can hurt me. Especially when they attack my communication weaknesses.

Anyways, if you continue to insult me I will assume you believe I'm a human, and are getting off on dissing my communication style. If you really believe I'm a robot, then prove it by saying nothing.

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#113

Post by pmlnr »

barfbagginus wrote: post #112
pmlnr wrote: post #101

Earlier quoted context omitted.

These comments have to be bot generated. It's so tiring.

I'm a person. I just write like that because I'm an awful writer and can't read a room. The idea - fixing noisy build codes with the help of AI - is actually a valid one. If you don't want to engage with the idea, then at least don't disparage me for being bot-like. I usually ignore non-constructive criticism. But sometimes devaluing insults can hurt me. Especially when they attack my communication weaknesses. Anyway…

It wasn't the writing style, it was the "let's put AI in it" content that triggered me. No, it's not a valid idea, trusting LLMs with this would be plain catastrophic with all it's hallucinations.

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#114

Post by lucb1e »

mappu wrote: post #25
senoralligator wrote: post #8

https://github.com/tukaani-project/.github/issues/2

That's quite funny - yes, not only is this a horrible wilful backdoor, it is also a GPL violation since the backdoor is a derived work without included source / distributed not in "the preferred form for modification".

Sadly, it looks like xz-utils is actually public domain. Only some of the scripts (like xzgrep) were GPL. So it is and remains only a joke, not an actual violation, hilarious as that would have been to enforce

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#115

Post by creato »

vodou wrote: post #41

A disturbing thought here is that unit tests opened up an attack vector. Without the tests this would have been much harder to hide.

For security critical projects, it seems like it would make sense to try to set up the build infrastructure to error (or at least warn!) when binary files are being included in the build. This should be done transitively, so when linux distros attempted to update to this new version of liblzma, the build would fail (or warn) about this new binary dependency.

I don't know how common this practice is in the linux distro builds. Obviously if it's common, it would take a lot of work to clean up to make this possible, even if it's even possible in the first place. It seems like something that would be doable with bazel, but I'm not sure about other build systems.

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#116

Post by ted_dunning »

edflsafoiewq wrote: post #93
jghn wrote: post #29

Earlier quoted context omitted.

Not only were they a co-maintainer, but if you're relying on code review to ensure correctness and security, you've already lost the battle. Code reviews are more about education and de-siloing.

In open source, code review is absolutely about correctness and security.

In some open source, this is true.

In an awful lot of open source, code review is a vanishingly rare commodity because there aren't enough committers left.

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#117

Post by everybackdoor »

ihsoy wrote: post #58
politelemon wrote: post #3

Thanks the simplified explanation and noisy image comparison is quite appreciated. It gives me a good grasp of what people mean by the sophistication involved. I also saw a comment on reddit mentioning that the "sandboxing" method was sabotaged with a dot. It's on the line just after "#include " you can see a dot all the way on the left. https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2... https://old.redd…

This is very likely just a mistake and not deliberate. a) absolutely nobody uses cmake to build this packet b) if you try to build the packet with cmake and -DENABLE_SANDBOX=landlock, the build just fails: https://i.imgur.com/7xbeWFx.png The "." does not disable sandboxing, it just makes it impossible to build with cmake. If anyone had ever actually tried building it with cmake, they would get the error and realize t…

[dead]

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#118

Post by pas »

barfbagginus wrote: post #112
pmlnr wrote: post #101

Earlier quoted context omitted.

These comments have to be bot generated. It's so tiring.

I'm a person. I just write like that because I'm an awful writer and can't read a room. The idea - fixing noisy build codes with the help of AI - is actually a valid one. If you don't want to engage with the idea, then at least don't disparage me for being bot-like. I usually ignore non-constructive criticism. But sometimes devaluing insults can hurt me. Especially when they attack my communication weaknesses. Anyway…

the idea is valid, but current LLMs suck, as the sibling comment says, they hallucinate too much, etc. that doesn't mean they won't improve enough in the next decade (especially coupled with clever loops, where the generated code is checked, end-to-end tested, static analyzed)

but this also shows what's really missing from these old projects, infrastructure, QA, CI, modern tools, etc.

and adding these requires humans in the loops, and every change needs to be checked, verified, etc.

and it's a hard task for a loose community of volunteers.

even the super fancy Rust community kind of shrugged and let crev die silently

https://github.com/crev-dev/cargo-crev

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#119

Post by johnisgood »

fullstop wrote: post #94
johnisgood wrote: post #67

Earlier quoted context omitted.

Yeah, again, "committed in plain sight" it was, was it not? Batting an eye on it or not is another matter.

If it's obfuscated or deceptive, as it was, it's really not plain sight.

Some of his commits were NOT obfuscated, committed in plain sight, yet no one has batted an eye, for reasons. So whatever floats your boat by adding that sentence, regardless, and however you may define "plain sight". It is a binary file to begin with.

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#120

Post by xorcist »

sgerenser wrote: post #37
asveikau wrote: post #12

Earlier quoted context omitted.

The commit messages for the test files claim they used an RNG to generate them. The guy making the release tarball then put the final line in the right place without checking it in.

What is the reason distros are still building from release tarballs rather than a git checkout that can be verified against a public git repo?

There could potentially be many things you would not want to commit to git. Binary files and generated files come to mind. There could also be transformations of code for performance or portability reasons. Or ones that require huge third party dependencies that are only used to the build script.

There are many potential reasons to publish a release tarball where some of these steps are already done. It could be done in a reproducible way. Look at sqlite for an example of an extremely well maintained open source library that publishes not one but two source code tarballs for various stages of the build.

These calls to change source code distribution just because it was a small part of the attack vector in this particular case seems misguided to me. It may still be a good idea but only as part of a much larger effort for reproducible builds. In itself it would accomplish nothing, apart from a wake of uncertainty that would only make future attacks easier. Especially in this case, where the maintainer could have acted in a number of other ways, and indeed did. The entirety of the backdoor was added in a regular git commit a long time ago.

Post reply on HN