Live data from Hacker News

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

git.tukaani.org

41–50 of 322 posts

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

#41

I’m not quite following what the diff here is suggesting - was this some cmake magic to detect if a feature was enabled, but the file had an intentional syntax error?

Autoconf and CMake both compile small test programs to verify that the feature in question actually works. The test programs almost never actually do anything; the just refer to the feature of function that they rely on. If there is a compile or linker error then the feature isn’t available. In this case the compiler always outputs an error because the test program doesn’t have valid C syntax.

Of course in practice you shouldn’t be writing each test program by hand. Autoconf has macros that generate them; you would only need to supply an identifier or at most a single line of code and the rest would be created correctly. I’m sure CMake is similar in that regard, so the first red flag is that they wrote a whole test program.

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

#42
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”, in the sense that C and C++ provide no better way to really know for sure that the functions you want to call really exist. In more modern languages we rely on metadata and semver, but none of that exists for C and C++.

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

#43

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 :(

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.

Ah yes but thanks to C being cursed due to includes and macros this is harder to do

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

#44
post #31

Earlier quoted context omitted.

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.

“The thing that controls scope is the count of certain nonprinting characters, which happen to come in multiple widths” is reasonably insane, yes

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

#45

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…

Yes mixing tabs and spaces is a big no no and rightfully throws an error now

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

#46

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.

Ah yes but thanks to C being cursed due to includes and macros this is harder to do

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

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

#48
post #34
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?

waiting for a new bot to scan everyone's repos to find "." and then spam every repo with false positives

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

#49
post #42

Earlier quoted context omitted.

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”, in the sense that C and C++ provide no better way to really know for sure that the functions you want to call really exist. In more modern languages we rely on metadata and semver, but none of that exists for C and C++.

I never test for this in this way in my C projects. I also rely on version tests only.

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

#50
Would it be reasonable to expect that this MR comes along with a test that shows that it does the thing it’s claiming to do? I’m not sure how that would work in this case.. have a test that is run on a system that is known to have landlock that does something to ensure that it’s enabled? Even that could be subverted, but it seems like demanding that kind of thing before merging “features” is a good step.
Post reply on HN