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

121–130 of 322 posts

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

#121

Post by brailsafe »

asveikau wrote: post #113
n2d4 wrote: post #95

Earlier quoted context omitted.

Unicode lookalikes would be detected by IDEs and other tools. There would be plausible deniability in a different situation, but this is the same author who implemented the backdoor and several similar changes that disable security features. I don't think the benefit of doubt is deserved here.

I'm not sure that an IDE will catch a syntax error in C code quoted inside a cmake script trying to test if things compile.

In either case, it would appear as added code, not different characters in the same code, so maybe about the same. If someone changed one character in an existing string though, I think it would be more likely caught visually by someone used to seeing accidental garbage show up

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

#122

Post by eacapeisfutuile »

kristjansson wrote: post #117
eacapeisfutuile wrote: post #104

Earlier quoted context omitted.

Why is that accepted? Serious question

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.

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

#123

Post by eacapeisfutuile »

snazz wrote: post #115
eacapeisfutuile wrote: post #111

Earlier quoted context omitted.

Yes but if that’s the sentiment how is this not as problematic as the npm ecosystem.

It’s similarly problematic but on a somewhat smaller scale and with fewer levels of nested dependencies.

I’m not sure this would be smaller scale? At least probably too early to tell?

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

#124

Post by cperciva »

glandium wrote: post #59
snnn wrote: post #51

So for each optional feature we may need three build options: 1. Force enable 2. Enable if available 3. Force disable Like, --enable_landlock=always --enable_landlock --disable_landlock

My rule of thumb is that things should never be disabled automatically. Make the test hard fail and print a message that the feature can be disabled.

In my code I have a bunch of routines optimized for different platforms, e.g. using x86 AESNI instructions. Not all compilers support them, and they don't even make sense when compiling for a different CPU architecture.

It's much simpler to say "enable this if we can compile it" rather than detecting the compiler and target platform and throwing a mess of conditional compilation into an autoconf script.

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

#125

Post by n2d4 »

asveikau wrote: post #113
n2d4 wrote: post #95

Earlier quoted context omitted.

Unicode lookalikes would be detected by IDEs and other tools. There would be plausible deniability in a different situation, but this is the same author who implemented the backdoor and several similar changes that disable security features. I don't think the benefit of doubt is deserved here.

I'm not sure that an IDE will catch a syntax error in C code quoted inside a cmake script trying to test if things compile.

A lot of IDE configurations, such as VSCode on the default config, highlight Unicode characters that are invisible/look like others (eg. cyrillic characters or non-breaking space) or even all non-ASCII characters, regardless of whether they're in a string or not.

Try pasting any of these into your IDE and see if it catches it. https://gist.github.com/StevenACoffman/a5f6f682d94e38ed80418...

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

#126

Post by jan3000 »

almostnormal wrote: post #81
GrayShade wrote: post #11

Only in CMake, this time. Not in the autotools version.

Does autotools compile only, or try to link? There's no main().

There is a main()...[0]

[0] https://git.tukaani.org/?p=xz.git;a=blob;f=CMakeLists.txt;h=...

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

#127

Post by Dalewyn »

kristopolous wrote: post #110
n2d4 wrote: post #95

Earlier quoted context omitted.

Unicode lookalikes would be detected by IDEs and other tools. There would be plausible deniability in a different situation, but this is the same author who implemented the backdoor and several similar changes that disable security features. I don't think the benefit of doubt is deserved here.

Ok there's a larger question here about the bazaar software development method. How can we ensure say, that Microsoft doesn't pay someone to throw a wrench in libre office development or Adobe to sabotage Gimp? There's lots of deception strategies for bad faith actors and given the paucity of people who actually do the work, it's really really hard to be picky. Especially with the complexity of library dependencies.…

>How can we ensure say, that Microsoft doesn't pay someone to throw a wrench in libre office development or Adobe to sabotage Gimp?

Microsoft and Adobe have reputations to uphold long into the future.

Is that infallible? Hell no it isn't, but consider that Jia Tan only needed to uphold his reputation insofar as getting his backdoor onto everyone's systems. Once that is done, his reputation or the lack thereof becomes a non-issue because his work is done. We're lucky we caught him just before the finish line.

The likelihood of demonstrably reputable parties like Microsoft and Adobe poisoning the well is practically nil because they don't have a finish line.

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

#128

Post by jrockway »

eru wrote: post #90
yegle wrote: post #35

Earlier quoted context omitted.

In Python, you only need to indent the `def test_foo` by an additional whitespace, to make it a locally scoped function instead of a proper test function.

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't let people check in dead code.

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

#129

Post by asvitkine »

hermitdev wrote: post #105
uecker wrote: post #46

Earlier quoted context omitted.

Huh, the code with a dot is not legal C. It is CMake issue that the test breaks here.

That's kind of the point. It's feature detection code. If the code cleanly compiles, the feature is assumed supported, otherwise, it's assumed not present/functional. This pretty common with autotools. The gotcha here is this innocuous period is not supposed to be syntactically valid. It's meant to be subtle and always disable the feature.

Shouldn't whatever is depending on xz supporting landlock be verifying that it's the case through blackbox tests or something? Otherwise a check like this even without the bug could end up disabling landlock if e.g. the compiler environment was such that a given header wasn't available...

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

#130

Post by deathanatos »

karmakaze wrote: post #15

I can't believe that system security is dependent on such a loose chain of correctness. Any number of things could have stopped this. + # A compile check is done here because some systems have + # linux/landlock.h, but do not have the syscalls defined + # in order to actually use Linux Landlock. Fix those headers on those systems to explicitly opt-out. What's the point of headers if they don't declare their capabilit…

I'm pretty certain the comment isn't accurate, and is just more subterfuge.
Post reply on HN