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

21–30 of 322 posts

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

#21

Post by [deleted] »

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.

[deleted]

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

#23

Post by jijijijij »

I don't know enough about C and complex builds, but the proposed change appears to be kind of a red flag, even without the breaking dot.

    -    check_include_file(linux/landlock.h HAVE_LINUX_LANDLOCK_H)
    ...
    +    check_c_source_compiles("
    +        #include
Is a compilation-test a legitimate/common/typical method to go about this?

Independently, of the breaking code, to me it seems accidental failing, or even accidentally not failing, would be in the nature of such an assessment... So, this commit seems to raise the question of "why?", even if you missed the dot, doesn't it? If a feature is formally available, but effectively broken somehow, wouldn't you want the compiler to complain, instead of the feature dropped silently? Is the reasoning in the code comment sound? Can you test, if syscalls are defined in another way?

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

#24

Post by secstate »

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…

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

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

#25

Post by capitainenemo »

secstate wrote: post #24
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…

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.

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

#26

Post by ronsor »

jijijijij wrote: post #23

I don't know enough about C and complex builds, but the proposed change appears to be kind of a red flag, even without the breaking dot. - check_include_file(linux/landlock.h HAVE_LINUX_LANDLOCK_H) ... + check_c_source_compiles(" + #include Is a compilation-test a legitimate/common/typical method to go about this? Independently, of the breaking code, to me it seems accidental failing, or even accidentally not failing…

> 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.

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

#27

Post by jijijijij »

ronsor wrote: post #26
jijijijij wrote: post #23

I don't know enough about C and complex builds, but the proposed change appears to be kind of a red flag, even without the breaking dot. - check_include_file(linux/landlock.h HAVE_LINUX_LANDLOCK_H) ... + check_c_source_compiles(" + #include Is a compilation-test a legitimate/common/typical method to go about this? Independently, of the breaking code, to me it seems accidental failing, or even accidentally not failing…

> 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.

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

#28

Post by kardos »

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…

Well, do we know if that commented code you quoted is accurate?

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

#29

Post by karmakaze »

kardos wrote: post #28
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…

Well, do we know if that commented code you quoted is accurate?

It's the content of TFA, so flag it if you believe it isn't.

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

#30

Post by kardos »

karmakaze wrote: post #29
kardos wrote: post #28

Earlier quoted context omitted.

Well, do we know if that commented code you quoted is accurate?

It's the content of TFA, so flag it if you believe it isn't.

Yes that is what I mean -- the commit in TFA is from the bad actor -- so the quoted comment is suspect..
Post reply on HN