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

Xz: Can you spot the single character that disabled Linux landlock?

git.tukaani.org

Post reply on HN
Print view View original

251–260 of 322 posts

Re: Xz: Can you spot the single character that disabled Linux landlock?

#251

Post by SAI_Peregrinus »

darthrupert wrote: post #205
cookiengineer wrote: post #139

Earlier quoted context omitted.

Some might say RMS was right all along.

I would actually say that he is completely wrong in this case. Open source created this problem.

The problem niver would have been fixed in proprietary software. And it's unlikely the problem would have been considered anything more than a 0.5s startup delay in some situations if xz were proprietary; it would have been reported as a performance issue to the malicious maintainer, who would have treated it as such and improved the startup time.

Re: Xz: Can you spot the single character that disabled Linux landlock?

#252

Post by rmast »

humanrebar wrote: post #225
rmast wrote: post #170

Earlier quoted context omitted.

It seems like there should be a way to catch these types of “bugs” - some form of dynamic analysis tool that extracts the feature detection code snippets and tries to compile them; if they fail for something like a syntax error, flag it as a broken check. Expanding macros on different OSes could complicate things though, and determining what flags to build the feature check code with — so perhaps filtering based on t…

I'd prefer if the ecosystem standardized on some dependency management primitives so critical projects aren't expected to invent buggy and insecure hacks ("does this strong parse?") in order to accurately add dependencies.

It would be interesting to see what the most common compile feature checks are for, and see what alternative ways could be used to make the same information available to a build system — it seems like any solution that requires libraries being updated to “export” information on the features they provide would have difficulties getting adoption (and not be backwards compatible with older versions of desired dependencies).

Re: Xz: Can you spot the single character that disabled Linux landlock?

#253

Post by asveikau »

londons_explore wrote: post #168
asveikau wrote: post #80

Earlier quoted context omitted.

It may be hard for him to re-establish trust. Maintaining xz for more than a decade then doing this would be quite a "long con" but if HN threads are any indication, many will still be suspicious. His commits on these links look legit to me. It's a sad situation for him if he wasn't involved.

The fact GitHub suspended his account too suggests that they might have info saying he is involved.

I think it was somewhat irresponsible to block everything. It hampers instigation of the repo's history. It's good that Lasse had another mirror.

Re: Xz: Can you spot the single character that disabled Linux landlock?

#254

Post by Tuna-Fish »

kristopolous wrote: post #88
dhx wrote: post #2

Answer: https://git.tukaani.org/?p=xz.git;a=commitdiff;h=f9cf4c05edd... Description of Linux's Landlock access control system if you are not familiar with it: https://docs.kernel.org/userspace-api/landlock.html xz official (maybe...) incident response page: https://tukaani.org/xz-backdoor/

This has plausible deniability on it. There's better ways to hide by swapping in Unicode lookalike characters. Some of them even pixel match depending on the font. Maybe I'm out of the loop but is intentionality settled here?

> Maybe I'm out of the loop but is intentionality settled here?

Yes. The exploit used a payload, that was stored in the tests directory as a binary compression test case, but which is very clearly a very intentional exploit payload.

All the sneaky stuff was about deploying that payload without it being obvious.

Re: Xz: Can you spot the single character that disabled Linux landlock?

#255

Post by Tuna-Fish »

zzzeek wrote: post #92
kristopolous wrote: post #88

Earlier quoted context omitted.

This has plausible deniability on it. There's better ways to hide by swapping in Unicode lookalike characters. Some of them even pixel match depending on the font. Maybe I'm out of the loop but is intentionality settled here?

the period right there on the left edge? if I saw that in a patch I'd be through the roof, that looks completely intentional

I distinctly remember having to remove such a superfluous . that I accidentally added into a file on multiple occasions.

If you are using vi and your left shift key is dodgy, that can easily happen by accident.

Re: Xz: Can you spot the single character that disabled Linux landlock?

#256

Post by rmast »

masklinn wrote: post #175
rmast wrote: post #170

Earlier quoted context omitted.

It seems like there should be a way to catch these types of “bugs” - some form of dynamic analysis tool that extracts the feature detection code snippets and tries to compile them; if they fail for something like a syntax error, flag it as a broken check. Expanding macros on different OSes could complicate things though, and determining what flags to build the feature check code with — so perhaps filtering based on t…

> if they fail for something like a syntax error, flag it as a broken check. A syntax error might be exactly what they’re looking for e.g. they’re feature testing a new bit of syntax or a compiler extension. > so perhaps filtering based on the type of error would be best done as part of the build system functionality for doing the feature checking. Which would require every compiler to have detailed, consistent, and…

At least for newer C++ standards it seems like there is decent support for feature test macros, which could reduce the need for a feature check involving compiling a snippet of test code to decide if a feature is available: https://en.cppreference.com/w/cpp/feature_test

Handling the output from several of the most recent GCC and Clang versions would probably cover the majority of cases, and add in MSVC for Windows. If the output isn’t from a recognized compiler or doesn’t match expectations, the only option is falling back to current behavior. Not ideal, but better than the current status quo…

Re: Xz: Can you spot the single character that disabled Linux landlock?

#257

Post by surajrmal »

thrtythreeforty wrote: post #6
jstanley wrote: post #4

Earlier quoted context omitted.

What does the dot do?

Fails the build, so that Landlock support is never enabled.

It feels like this is a poor way to determine if a feature should be enabled. There are just too many reasons it could fail, and default off on compilation failure just seems like a glaring security bug. If this is a common practice, it seems like the community should rethink this choice.

Re: Xz: Can you spot the single character that disabled Linux landlock?

#258

Post by kevincox »

phoe-krk wrote: post #7
dhx wrote: post #2

Answer: https://git.tukaani.org/?p=xz.git;a=commitdiff;h=f9cf4c05edd... Description of Linux's Landlock access control system if you are not familiar with it: https://docs.kernel.org/userspace-api/landlock.html xz official (maybe...) incident response page: https://tukaani.org/xz-backdoor/

So that function checked if the following C code compiled, and only in that situation enabled the landlock? Except that lone period, hard to recognize because of its small size and proximity to the left edge of the diff, caused the C code to become always invalid, hence keeping the landlock always disabled? That's both vilely impressive and impressively vile. I didn't even spot it on my first read-through.

It also shows how brittle these sorts of checks are in general. I really think that this auto-disable of features based on compilation was a big mistake. It is not only very annoying when packaging things (Why does feature X not work? Because you forgot to include libY in the build environment of course) but they also fail silently even if intended. While this `.` was almost certainly malicious it is easy to imagine an accidental break. Maybe a minor typo or `-Werror`is enabled any one of these functions was marked as must use or something similar.

It seems like it is infinitely better to have a default set of features and explicitly require the user to say `--enable-x --disable-y` as needed. Then error out if a required library isn't available. (Preferably saying which feature requires it.)

Re: Xz: Can you spot the single character that disabled Linux landlock?

#259

Post by kevincox »

Cloudef wrote: post #216

This is why I really don't like configure style build systems that automatically enable / disable features. When I want something I explicitly opt-in for it. If there's good reason for feature to be default, then instead explicitly allow opt-out.

This is a huge pain when packaging things. You set up the package, add dependencies until it builds and think you are done. But they feature X is missing. What? Oh, it was silently disabled because libY isn't available. Ok, go back and add it. Then a user reports that feature Z isn't available...

Yeah, just have a default set of features and allow `--enable-a --disable-b` as needed.

The fact that it silently swallows bugs in the check is just another problem of it.

Post reply on HN