Live data from Hacker News

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

git.tukaani.org

11–20 of 322 posts

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

#14
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)?

The library is entrenched enough, trusted enough, and its main developer has long internet breaks because of mental health problems.

Plus, you do not backdoor the library itself, but the tools using it. "Reflections on trusting trust" style.

Sounds like a perfect plan, until it isn't.

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

#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 capabilities?

Also why isn't there a single test after a binary blob (even when compiled from open source) is made to ensure security is in-tact?

I wouldn't even ship a website checkout without end-to-end tests for core capabilities. There must be a priority misalignment of adding features > stability.

Edit: I hope the 'fix' isn't to remove the '.'--I just saw the other post on HN that shows removing the '.'

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

#16
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/

This is so vile that even if caught red-handed during PR one could shrug off "oh, my IDE's auto formatting did this".

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

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

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 pretty silly to me to have whitespace play such a major significant role, besides the fact that I find it visually harder to read, like text without punctuation or capitalisation.

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

#19

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?

That's exactly right. It was checking if the c code compiled to detect the landlock feature, and there was a single period in the middle of the code that made it always fail to compile and thus silently leave the feature disabled.
Post reply on HN