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

31–40 of 322 posts

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

#31

Post by katbyte »

capitainenemo wrote: post #18
082349872349872 wrote: post #10

Earlier quoted context omitted.

I just got a little more respect for pythonic whitespace-sensitivity EDIT: come to think of it, even that might not have done much here, where well-formedness is the issue :(

Yeah, if anything, python worsens the situation. I had a friend DOS our server because he accidentally inserted a tab, causing the illusion that one statement was inside a block but was actually outside it. He swore off python at that point. I personally avoid the language, but I understand due to issues like that these days mixing tabs and spaces is an error (or is it just a warning?) by default. Regardless, still p…

white space as a delimiter is why i never use python.

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

#32

Post by ninkendo »

jijijijij wrote: post #27
ronsor wrote: post #26

Earlier quoted context omitted.

> Is a compilation-test a legitimate/common/typical method to go about this? Yes—in fact, compilation tests are often the only way you can tell if a feature actually works. It's extremely common for C build systems to detect and work around weird systems.

Is this by design, or by legacy? I mean, is there a better way to do this? Seems really flawed to me.

It’s by design. The job of autotools is to find “ground truth” about whatever environment you’re compiling against. It’s meant to discover if you can use a feature by actually seeing whether it works, not just by allow-listing a known set of compiler or library versions. This is because the whole point is to allow porting code to any environment where it’ll work, even on compilers you don’t know about. Think back to a time when there were several dozen Unix vendors, and just as many compilers. You don’t want your build script to report it can’t compile something just because it isn’t aware of your particular Unix vendor… you want it to only fail if the thing it’s trying to do actually doesn’t work. The only way to do this is by just testing if certain code compiles and produces the expected result.

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

#33

Post by naikrovek »

katbyte wrote: post #31
capitainenemo wrote: post #18

Earlier quoted context omitted.

Yeah, if anything, python worsens the situation. I had a friend DOS our server because he accidentally inserted a tab, causing the illusion that one statement was inside a block but was actually outside it. He swore off python at that point. I personally avoid the language, but I understand due to issues like that these days mixing tabs and spaces is an error (or is it just a warning?) by default. Regardless, still p…

white space as a delimiter is why i never use python.

> white space as a delimiter is why i never use python.

Whitespace is a delimiter in (almost?) all languages humans use.

Whitespace determining which scope you’re in is one of the many problems of making whitespace significant, which might be what you meant.

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

#34

Post by dagmx »

pxx wrote: post #12

What was even the game here? Eventually even more backdoors, ones that would have more plausible deniability? Afaict neither the oss-fuzz nor this change would actually discover the found backdoor. But why put your backdoor eggs into one basket (library)?

Who says it was just the one library though?

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

#35

Post by yegle »

082349872349872 wrote: post #10
phoe-krk wrote: post #7

Earlier quoted context omitted.

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.

I just got a little more respect for pythonic whitespace-sensitivity EDIT: come to think of it, even that might not have done much here, where well-formedness is the issue :(

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.

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

#36

Post by secondcoming »

jijijijij wrote: post #27
ronsor wrote: post #26

Earlier quoted context omitted.

> Is a compilation-test a legitimate/common/typical method to go about this? Yes—in fact, compilation tests are often the only way you can tell if a feature actually works. It's extremely common for C build systems to detect and work around weird systems.

Is this by design, or by legacy? I mean, is there a better way to do this? Seems really flawed to me.

Back in the day when people compiled source from tarballs on their personal machines, the autoconf script would query your system to see what functionality it supported. It did this by trying to compile small programs for each feature. If the compilation failed it assumes the feature is unavailable on your system and a flag is set/unset for the rest of the build.

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

#37

Post by kccqzy »

jijijijij wrote: post #27
ronsor wrote: post #26

Earlier quoted context omitted.

> Is a compilation-test a legitimate/common/typical method to go about this? Yes—in fact, compilation tests are often the only way you can tell if a feature actually works. It's extremely common for C build systems to detect and work around weird systems.

Is this by design, or by legacy? I mean, is there a better way to do this? Seems really flawed to me.

Have you ever tried to manually build something from a release tarball by starting with ./configure? If so, have you observed how many times the compiler is invoked in this configure phase before you even run make?

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

#38

Post by philsnow »

082349872349872 wrote: post #10
phoe-krk wrote: post #7

Earlier quoted context omitted.

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.

I just got a little more respect for pythonic whitespace-sensitivity EDIT: come to think of it, even that might not have done much here, where well-formedness is the issue :(

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.

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

#39

Post by _visgean »

capitainenemo wrote: post #25
secstate wrote: post #24

Earlier quoted context omitted.

Mixing tabs and spaces usually throws a runtime exception. I'm not gonna make a value judgement about that, but your story doesn't make sense based on how I understand py3 Edit, sorry, shoulda read your whole commebt before replying

Yep. It was a few years ago while that was stilled allowed (as I'd noted ;) ) but regardless. Significant whitespace is just annoying.. There's a lot of things that render as whitespace, and source code one might be reviewing could be printed wrapped or copied and pasted in odd ways. Other languages are more robust to this.

Never had this happen, this is largely eliminated by using tools like black or other autoformatters.

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

#40

Post by asveikau »

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?
Post reply on HN