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

91–100 of 137 posts

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#91

Post by barfbagginus »

jghn wrote: post #29
plg94 wrote: post #17

Earlier quoted context omitted.

the bad actor was a co-maintainer of the repo (and even more active than the original maintainer for quite some time) with full commit rights. This was strait committed to master, no PR and no review required. edit: also this was heavily obfuscated in some binary files that were marked as test files ("good" and "bad" xz compressed test file). No way to spot this if you don't know what you're looking for.

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.

Assume your co-contibutor was not always malicious. They passed all past vetting efforts. But their motives have changed due to a secret cause - they're being extorted by a criminal holding seriously damaging material over them and their family.

What other controls would you use to prevent them contributing malicious commits, besides closely reading your co-contributor's commits, and disallowing noisy commits that you don't fully comprehend and vouch for?

We assume that it'd be unethical to surveil the contributor well enough to detect the change in alliance. That would violate their privacy.

Is it reasonable to say, "game over, I lose" in that context? To that end, we might argue that an embedded mole will always think of ways to fool our review, so this kind of compromise is fatal.

But let's assume it's not game over. You have an advanced persistent threat, and you've got a chance to defeat them. What, besides reviewing the code, do you do?

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#93

Post by edflsafoiewq »

jghn wrote: post #29
plg94 wrote: post #17

Earlier quoted context omitted.

the bad actor was a co-maintainer of the repo (and even more active than the original maintainer for quite some time) with full commit rights. This was strait committed to master, no PR and no review required. edit: also this was heavily obfuscated in some binary files that were marked as test files ("good" and "bad" xz compressed test file). No way to spot this if you don't know what you're looking for.

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.

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#94

Post by fullstop »

johnisgood wrote: post #67
fullstop wrote: post #52

Earlier quoted context omitted.

It really wasn't, though. commit 74b138d2a6529f2c07729d7c77b1725a8e8b16f1 Author: Jia Tan Date: Sat Mar 9 10:18:29 2024 +0800 Tests: Update two test files. The original files were generated with random local to my machine. To better reproduce these files in the future, a constant seed was used to recreate these files. diff --git a/tests/files/bad-3-corrupt_lzma2.xz b/tests/files/bad-3-corrupt_lzma2.xz index 926f95b0.…

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.

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#95

Post by edflsafoiewq »

pelasaco wrote: post #78
mrb wrote: post #62

Earlier quoted context omitted.

But what are you suggesting exactly? The code fragment you quoted was awk code. Awk is a generic programming language. Any programming language can be written to be complex and unreadable.

> Any programming language can be written to be complex and unreadable. The question is you as lead developer, reviewing a commit with a complex and unreadable code snippet, what would you do?

You would reject it of course, which is exactly why this code never appeared in a commit. The stage 0 of the exploit was not checked in, but directly added to the autogenerated build script in the release tarball, where, even if someone did review the script, it looks plausibly like other autogenerated build gunk. The complex and unreadable scripts in the further stages were hidden inside binary test files, so no one reviewing the commit that added them (https://git.tukaani.org/?p=xz.git;a=commit;h=cf44e4b) would directly see that code.

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#96

Post by ncr100 »

notnmeyer wrote: post #60

i don’t have a better answer, but this convoluted mess of bash is a smell isn’t it? i live in a different part of the dev world, but could this be written to be less obtuse so it’s more obvious what’s happening? i get that a maintainer can still get malicious code in without the same rigor as an unaffiliated contributor, but surely there’s a better way than piles of “concise” (inadvertently obfuscated?) code?

(NOTE: I may misunderstand the risk of the XV backdoor - "it exec'd"..., and so my premise may be irrelevant to this convo.)

Is there a way to run BASH such that it does not allow EXEC'ing things? Like, have a "secure mode" for bash?

EDIT: For xv's configure script, I cannot imagine how one could run BASH in any hypothetical "secure mode". So, Nvm.

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#97

Post by paulmd »

mistrial9 wrote: post #89
minimax wrote: post #65

> if this was found by accident, how many things still remain undiscovered. This, to me, is the most important question. There is no way Andres Freund just happened to find the _only_ backdoored popular open source project out there. There must be like a dozen of these things in the wild?

"(B)urn (A)ll (S)atanic (H)elper-scripts" ? get the kindling?

thou shalt not make a machine in the likeness of a human mind

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#98

Post by paulmd »

edflsafoiewq wrote: post #90
benlivengood wrote: post #76

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/linke…

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.

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.

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#99

Post by gravescale »

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…

I really hate writing these compile/build time conditional things. It's hard to have tests that it's enabled when it should be and disabled when it isn't, especially if it's in the build system where there's no unit test framework.

And that's with the failure party being just accidentally borking it so the test always fails or always succeeds when it shouldn't. You can see why it's a juicy target for malicious actions.

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#100

Post by oogali »

sega_sai wrote: post #4

Did anyone search github yet for similar head | tail tricks ? I doubt it was invented just for this.

I've generally seen this with Unix installers from commercial software vendors.

You get a giant .sh file that displays a license, asks you to accept, then upon acceptance, cats itself, pipes through head/tail, into cpio to extract the actual assets.

Post reply on HN