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

171–180 of 322 posts

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

#171

Post by takeda »

astrange wrote: post #142
Aurornis wrote: post #5

Earlier quoted context omitted.

The function is “check_c_source_compiles”. The comment indicates that the intention is to confirm that the Landlock functionality can be compiled on the system, in which case it will be enabled. The stray dot isn’t valid C, so it will never compile. By ensuring it can never compile, Landlock will never be enabled.

configure would print that it's not enabled, so it seems like the kind of thing people would eventually notice.

Looks like he only introduced that "bug" in CMake. Was there migration in progress from autoconf to cmake?

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

#172

Post by takeda »

eacapeisfutuile wrote: post #122
kristjansson wrote: post #117

Earlier quoted context omitted.

He had unfettered access to xz’s git?

Isn’t it a bit ironic with how much code everyone depends on that can freely be altered by some unknown party, while so much time goes into code reviews to verify internal changes at most companies.

And he was in the project for just 2 years.

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

#173

Post by IshKebab »

This is surprisingly obvious. I mean it's a clever technique to disable the feature and a really plausible commit. But then why did they go with an obvious syntax error instead of just misspelling something. E.g. would you have spotted it if the mistake was `PR_SET_NO_NEW_PRIV`?

More plausibly deniable too.

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

#174

Post by kijin »

bawolff wrote: post #153
usr1106 wrote: post #148

Where/how was landlock supposed to be used? I guess you cannot really use it in a generic library like compression/decompression. The library has no clue what the program is supposed to do and what should be restricted. For a program it might be clearer. The sshd attack was using liblzma as a library. So disabling landlock seems unrelated? A sign that there is more bad code waiting to be detected / had been planned t…

Its weird. Like i would consider doing two unrelated backdoor-esque things in the same project really sloopy. Seems like it just significantly increases the risk of being discovered for minimal gain. Its very confusing. Parts of this sega seem incredibly sophisticated while other parts seem kind of sloppy.

Dude is a developer just like the rest of us. We all try to write clever code from time to time, but at other times write sloppy crap. Especially if there's a boss insisting on a tight deadline.

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

#175

Post by masklinn »

rmast wrote: post #170
masklinn wrote: post #159

Earlier quoted context omitted.

Error-ing is the point here and what the period achieved. It’s a feature detection snippet so if it fails to compile the feature is disabled.

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 machine-readable failure reporting.

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

#176

Post by TLLtchvL8KZ »

asveikau wrote: post #40
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/

It seems like Lasse Collin is back on the scene and maybe pissed?

I worry about his home/personal system, this guy seems to have befriended Lasse in order to get the position, is it possible Lasse himself has been compromised?

I'd be nuking everything, possibly even disposing of hardware and setting up a new verifiable online identity on a clean system/hardware.

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

#177

Post by tsimionescu »

mewpmewp2 wrote: post #85
philsnow wrote: post #38

Earlier quoted context omitted.

AST diffs instead of textual diffs might have helped here (to spot the `.` making the code un-compilable). Edit: oof, though the stray character in question is inside a perfectly legitimate C string, so to catch this, any such diffs would need to Matroyshka down and that seems unsolvable / intractable.

I think main issue was that it was embedded in the file itself like that. Would have preferred to have it in a separate valid C file with syntax highlighting etc and being parsed from that file.

Perhaps, but given how most build systems work, that would complicate things in other ways (since build systems often try to compile all .c files).

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

#178

Post by cricalix »

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.

Or you know, they just reacted with a ban hammer on all accounts related to xz and to heck with innocence.

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

#179

Post by rurban »

SV_BubbleTime wrote: post #131
Terr_ wrote: post #119

Earlier quoted context omitted.

For those squinting, the "landlock" regular "c" is replaced with a Cyrillic U+0441.

Is there a GCC option to error on non-standard English characters?

Not yet. I was working on the standardization for C23, but this was postponed to C26, and has not much support. MSVC and SDCC liked it, CLANG and GC not so much.

Here is my bad variant of the feature, via confusables: https://github.com/rurban/gcc/tree/homoglyph-pr103027

The better variant would be to use my libu8ident, following UTR 39. I only did that for binutils.

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

#180

Post by asddubs »

jrockway wrote: post #128
eru wrote: post #90

Earlier quoted context omitted.

No, not if you have any sane linter or formatter involved. They wouldn't let you get away with indenting by a single space, but only by multiples of whatever you normally use in the rest of your program.

I mean, some CI system should be checking that "if_code_compiles()" blocks compile somewhere. It should be an error until the CI system has that header and can test both variants. People are really quick to add optionality like this without understanding the maintenance cost. (Every boolean feature flag increases the number of variants you need to test by 2!) Either make a decision, or check that both sides work. Don…

multiplies it by 2, not increases
Post reply on HN