Live data from Hacker News

Xz/liblzma: Bash-stage Obfuscation Explained

gynvael.coldwind.pl

131–137 of 137 posts

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#131
post #118

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…

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…

> Shows what's really missing from these old projects

Well that's kind of the opportunity there, right? Usually there are more modern solutions:

- use GH actions to do multi platform / multi-compiler tests

- use modern packaging solutions (eg, convert setup.py to a Pep 518 style pyproject.toml)

- publish to package repos (eg, many python projects are not on pypi)

This kind of work was baffling to me before I started working with gpt4 - my main struggle was understanding existing solutions, reading the documentation of existing build and packaging systems, and troubleshooting complex error logs.

At first gpt4 simply helped me when my own reading inabilities kicked my butt. But then I got better at understanding existing solutions and proposing new work. Now I can describe things at a high level and give GPT the right context it needs to propose a good first draft solution. And I understand things well enough to manually validate the solution. On top of that we also go ahead and test the solution, and fix issues that come up.

As a result I'm simply not scared of build systems anymore, no matter how byzantine or poorly documented. I'm vastly more capable of completing improvements then I was a year ago, and have half a dozen major upgrades under my belt.

I don't think that this will ever work automatically given that even gpt4 still hallucinates and lacks big picture thinking and awareness of up to date best practices.

However I do see it as a huge Force Multiplier for our loose community of volunteers.

We'll have to break down the assumptions that GPT always hallucinates uncontrollably. That's simply not true - GPT4 usually hallucinates in ways that are easy to fix by checking documentation and running tests. It usually introduces less errors than I do if I'm new to a system, and with its help I can correct more errors than I can on my own.

I see it as a huge win, if we can educate people in the community.

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#132
post #61

Earlier quoted context omitted.

> No way to spot this if you don't know what you're looking for. I would expect most people to at least ask for more clarification on random changes to `head` offsets, honestly - or any other diff there. If they had access to just merge whatever with no oversight, I guess the blame is more on people using this in other projects without vetting their basic security of projects they fully, implicitly trust, though. As…

> without vetting their basic security of projects they fully this sort of vetting you're talking about is gonna turn up nothing. Most vetting is at the source code level anyway, not in the tests, nor the build files tbh. It's almost like a checkbox "cover your ass" type work that a hired consultant would do. Unless you're someone in gov't/military, in which case yes, you'd vet the code deeply. But that costs an arm…

I meant more in the sense that if you're creating an open source project, especially one with serious security implications, you should be extremely aware that you have a dependency that a single individual can update with minimal oversight. Somewhat idealistic take, maybe, but not something you should just be able to ignore either.

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#133
post #118

Earlier quoted context omitted.

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…

> Shows what's really missing from these old projects Well that's kind of the opportunity there, right? Usually there are more modern solutions: - use GH actions to do multi platform / multi-compiler tests - use modern packaging solutions (eg, convert setup.py to a Pep 518 style pyproject.toml) - publish to package repos (eg, many python projects are not on pypi) This kind of work was baffling to me before I started…

Yes, ChatGPT is a great learning resource, great for fearless exploration, and is available 0-24 and scalable (whereas the usual maintainers are, unfortunately more often than not, the diametrical opposite of these).

The big elephant in the room problem is that software/tech/opensource is this Schroedinger's safest cat.

Because on one hand we have 3-redundant hardware and independent implementations and we can go to the moon and back with it, and let it drive our cars, and we have LetsEncrypt, and browsers pushing for TLS1.3 everywhere, and Civil Infrastructure Platform with all the extended lifetime, Jepsen tests, and TLA+ and rewriting the world in Rust ... and on the other hand billions of people blindly download/open anything on their Android 6 device with expired root TLS certs and running unpatched Linux checks notes 3.18.10 ... WTF.

Sure, that might not be the most apples-to-apples comparison (or maybe it's apples v2 to v42), but this is mostly the reality everywhere ... I have very good friends working in ITsec (from managers to bugbounty-reapers), and ... things are highly comical.

It's the whole culture that's lacking. Sure, it's relatively new, a mere decade basically, so we'll see. (And incidents like this are definitely raising awareness, maybe even "vindicating" some people who boldly said fuck this shit upon seeing autoconf/automake/make/configure and started to write yet another build system.)

All in all, the pressure is rising, which will probably lead to some phase transition, and maybe - if we are lucky - systems and platform with top-to-bottom secure-by-default engineering mindset will start to precipitate out of this brewing chaos. (And this might make it even less fun to do open source maintenance.)

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#134

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.

If you add the dot to Rust it doesnt break?

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#135

Earlier quoted context omitted.

OMG that's evil. The diff just shows: + +. + and the dot goes unnoticed

I wonder why they didn't use a non-breaking space or similar. I guess it's possible a nbsp would stand out even more.

Plausible deniability probably. A dot could be a typo, a NBSP is less likely.

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#136
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…

> why the fuck is dot a shortcut for `source`?!

The dot is the standard POSIX name for the command [0], `source` is a bash-specific alias.

[0] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...

Re: Xz/liblzma: Bash-stage Obfuscation Explained

#137
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?

But this awk code was not committed in the clear so it was not possible to review. It was hidden in a binary file, compressed and encrypted.
Post reply on HN