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

91–100 of 322 posts

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

#91

Post by eru »

tomoyoirl wrote: post #44
naikrovek wrote: post #33

Earlier quoted context omitted.

> 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

Which non-printing characters are you talking about? Whitespace characters are very much printable.

Yes, I agree that Python should just forbid tabs. As a second best, you can tell your linter (and/or formatter) to forbid tabs (and any weird unicode whitespace). That's basically the equivalent of compiling your C with -Wall.

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

#92

Post by zzzeek »

kristopolous wrote: post #88
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/

This has plausible deniability on it. There's better ways to hide by swapping in Unicode lookalike characters. Some of them even pixel match depending on the font. Maybe I'm out of the loop but is intentionality settled here?

the period right there on the left edge? if I saw that in a patch I'd be through the roof, that looks completely intentional

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

#93

Post by CGamesPlay »

On an unrelated note, this malware team has assembled a great dataset for training AIs on identifying security problems. Every commit has some security problem, and the open source community will be going through and identifying them. (Thanks, maintainers, for the cleanup work; definitely not fun!)

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

#94

Post by eru »

ratmice wrote: post #52
naikrovek wrote: post #33

Earlier quoted context omitted.

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

Regarding your almost query. There was a debate over Ogham space mark in unicode. It is considered whitespace though, with the rationale that it is sometimes visible, but sometimes invisible. Depending upon whether the text has a stem-line. That doesn't make the set of non-whitespace delimited languages empty. Perhaps there is one with an always-visible delimiter that didn't get the whitespace justification, but does…

> That doesn't make the set of non-whitespace delimited languages empty.

Well, there's also the opposite: Goldman Sachs's Slang allows space as part of identifiers.

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

#95

Post by n2d4 »

kristopolous wrote: post #88
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/

This has plausible deniability on it. There's better ways to hide by swapping in Unicode lookalike characters. Some of them even pixel match depending on the font. Maybe I'm out of the loop but is intentionality settled here?

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.

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

#96

Post by eru »

_visgean wrote: post #39
capitainenemo wrote: post #25

Earlier quoted context omitted.

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.

And/or linters.

This issue is no worse that having multiple different variables that look the same and only in their obscure same-looking unicode symbols.

A linter can handle this. As can a decent font, or editor settings.

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

#97

Post by eru »

philsnow wrote: post #38
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 :(

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.

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

Not sure, you could also just forbid code that's too complex to analyse without going down a rabbit hole. Instead of trying to go down the rabbit hole.

In general, it's hard to analyse arbitrary code. But we don't have to allow arbitrarily complex code when doing code review.

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

#98

Post by eru »

XorNot wrote: post #72
Aeolun wrote: post #64

Earlier quoted context omitted.

I feel like my version control system is better about highlighting the changed characters than these solid green or red strings.

I don't love unified diffs as a rule either. They're very noisy to read in general. A side by side in something like "meld" will highlight changes but also means you're reading the full context as it will exist in the code base. My number one complaint about "code review" is the number of people who simply run their eyes over the diff (in private orgs) because management says "code review" and that's as far as they e…

I love unified diffs for many applications. You are right that side by side diffs have their uses, too.

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

#100

Post by Randalthorro »

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…

He introduced a whole new testing framework then slowly put a backdoor in it over 2 years
Post reply on HN