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

121–130 of 137 posts

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#121

Post by xorcist »

jijijijij wrote: post #80
deng wrote: post #72

Earlier quoted context omitted.

> IIRC only the "binary" files where added secretly, right? But the build script was there for people to inspect? Yes, but it is important to note that these malicious m4 scripts were only present in the tar file. They were not checked into the git repo, which is why distros that actually built from git were not affected. Totally agree with the problem of cryptic scripts in the build process, but unfortunately, if yo…

> Yes, but it is important to note that these malicious m4 scripts were only present in the tar file. Looks like I got it backwards then. I thought, the test-files where the sneaky addition. Guess nobody cared for them... > if you maintain a project that needs to support a ton of different platforms, you don't have that much choice in your build tools Yeah, but, if possible, we could start porting those things into b…

This is just Docker being Docker. If that type of thing is interesting to you, start reading the source code.

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#122

Post by fullstop »

johnisgood wrote: post #119
fullstop wrote: post #94

Earlier quoted context omitted.

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.

Can you point one out?

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#123

Post by whywhywhywhy »

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?

It wasn’t found accidentally, he felt it. There’s a difference.

Next one will definitely be less careless with adding time to it’s execution.

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#124

Post by otabdeveloper4 »

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…

"AI" is not actually intelligence, it's an advanced madlibs generator. No, you do not want it anywhere near your source code.

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#125

Post by noctune »

zzzeek wrote: post #54

can we start considering binary files committed to a repo, even as data for tests, to be a huge red flag, and that the binary files themselves should instead, to the greatest extent possible, be generated at testing time by source code that's stated as reviewable cleartext (though I think this might be very difficult for some situations). This would make it much harder (though of course we can never really say "impos…

I don't really agree - I think its more the case that the build system should be able to prove that tests and test files cannot influence the built artifact. Any test code (or test binary files) going into the produced library is a big red flag.

Bazel is huge and complicated, but it allows making those kinds of assertions.

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#126

Post by bicolao »

creato wrote: post #115
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 distr…

seems easily worked around with base64 and friends.

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#127

Post by ds9soft »

The whole C land, including build tools, old unix utils, is a security mess waiting to be exploited, and it's going to be exploited. Just look how easy it's to break everything with a single dot. It's time people realize we can't bet the world's security on C.

Please use Ada or Rust with modern tooling.

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#128

Post by [deleted] »

pmlnr wrote: post #113
barfbagginus wrote: post #112

Earlier quoted context omitted.

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.

[deleted]

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#129

Post by barfbagginus »

pmlnr wrote: post #113
barfbagginus wrote: post #112

Earlier quoted context omitted.

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.

You're assuming a few things:

1. I'm using GPT 3.5 level LLMs

2. I'm not using humans in the loop to verify solutions

3. I'm not using testing or self-correcting strategies to verify and correct solutions

Given these assumptions, then I agree - hallucinations eat your lunch, big time.

What I proposing is using GPT4 to annotate existing solutions and propose drafts, with humans in the loop to approve and revise, and self-correcting workflows to test solutions.

And I'm basing this off my own experience with upgrading project build and packaging systems, using the AI to annotate, draft, fix errors, etc.

I have full oversight over the final solution. And it has to be simple and clean, or I write another draft.

The result is that I can understand and upgrade build and packaging solutions maybe five or ten times faster than I ever could before. Even quite cryptic legacy systems that I would never touch before.

Now multiply that times every open source developer in the world.

That's why I think we could execute a major build and packaging modernization effort.

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#130

Post by dang »

swells34 wrote: post #75
1letterunixname wrote: post #30

Never allow complexity in code or so-called engineers who ask to merge tons of shitty code. Get rid of that shit and don't trust committers blindly. Anyone who enables this crap is also a liability.

[flagged]

You can't attack other users on HN, no matter how annoying another comment is or you feel it is. We have to ban accounts that post this way, so please don't do it again. You've unfortunately been doing it repeatedly:

https://news.ycombinator.com/item?id=39494039

https://news.ycombinator.com/item?id=39441168

If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.

Post reply on HN