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

301–310 of 322 posts

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

#301

Post by mike_hearn »

usr1106 wrote: post #148

Where/how was landlock supposed to be used? I guess you cannot really use it in a generic library like compression/decompression. The library has no clue what the program is supposed to do and what should be restricted. For a program it might be clearer. The sshd attack was using liblzma as a library. So disabling landlock seems unrelated? A sign that there is more bad code waiting to be detected / had been planned t…

You can use it and it's a good idea, although it's meant to stop exploits rather than deliberate backdoors.

The idea is that the library starts a separate thread to do any complex operation and then waits for it in the API call the user code made. The thread landlocks itself and then begins the operation. If something goes wrong the code is confined.

Of course in this case it doesn't work because the sandbox is controlled by the attacker, so they can just turn it off or make it weaker than it should be. But you can also do things other ways.

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

#302

Post by p10_user »

dylan604 wrote: post #48
dagmx wrote: post #34

Earlier quoted context omitted.

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

worse yet some moron sets the search type to "regex"

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

#303

Post by tsimionescu »

kzrdude wrote: post #300
tsimionescu wrote: post #296

Earlier quoted context omitted.

Actually the interaction with libc is not like what you expect from a standard library in other languages. Even apart from being very small, it's not really a single library - you have glibc, musl lib c, the BSDs each have their own libc, Mac OS has its own, Windows has its own. And if you want a very portable C program, you can't assume your program will run with the libc on your system, you need to take into accoun…

libc is kind of special, but surely many language environments have different standard lib implementations? Java has OpenJDK and Oracle JDK.

AzulJDK and Android JDK would be better examples, as Oracle JDK is just an Oracle-blessed build of OpenJDK.

The difference from libc though is that there is no problem in distributing a program with your preferred JDK, and multiple Java programs can live on the same system while each using its own JDK and even communicate risk free with each other.

Also, different JDKs are significantly more similar in the API they offer to Java programs than different libc are - at least for a common core of functionality.

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

#304

Post by worik »

eru wrote: post #295
worik wrote: post #289

Earlier quoted context omitted.

> Well, in C the visual indentation and the meaning of the code (given by {}) can diverge. How?

The compiler doesn't check your indentation at all. (OK, not true, these days you get warnings for misleading indentation.) But here's an example of misleading indentation in C: if(some condition) do something; { do something else; } do another thing; You can stretch 'some condition' out over multiple lines and have some more parents inside of it, to make it more confusing. See also https://softwareengineering.stacke…

I see.

Yes

I class that as a bug in the original C specification

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

#305

Post by eru »

worik wrote: post #304
eru wrote: post #295

Earlier quoted context omitted.

The compiler doesn't check your indentation at all. (OK, not true, these days you get warnings for misleading indentation.) But here's an example of misleading indentation in C: if(some condition) do something; { do something else; } do another thing; You can stretch 'some condition' out over multiple lines and have some more parents inside of it, to make it more confusing. See also https://softwareengineering.stacke…

I see. Yes I class that as a bug in the original C specification

But you either make visual indentation significant, or you risk having a discrepancy between visual indentation and what the language sees.

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

#306

Post by worik »

eru wrote: post #305
worik wrote: post #304

Earlier quoted context omitted.

I see. Yes I class that as a bug in the original C specification

But you either make visual indentation significant, or you risk having a discrepancy between visual indentation and what the language sees.

> But you either make visual indentation significant...

That would be Python. I do not like it, which does not mean it is bad, it is a matter of taste

The alternative is you say "blocks are delimited by {}"

`if(foo) bar` should be invalid

`if(foo){bar}` is OK by me. Worik's tick of approval

(Neither is valid C I think)

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

#307

Post by BobbyTables2 »

kevincox wrote: post #259
Cloudef wrote: post #216

This is why I really don't like configure style build systems that automatically enable / disable features. When I want something I explicitly opt-in for it. If there's good reason for feature to be default, then instead explicitly allow opt-out.

This is a huge pain when packaging things. You set up the package, add dependencies until it builds and think you are done. But they feature X is missing. What? Oh, it was silently disabled because libY isn't available. Ok, go back and add it. Then a user reports that feature Z isn't available... Yeah, just have a default set of features and allow `--enable-a --disable-b` as needed. The fact that it silently swallows…

Worse, it enables features based on local system packages whose dependencies aren’t captured by the package dependencies.

At least for a time, this was a horrible problem in Yocto.

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

#308

Post by snnn »

xorcist wrote: post #298
snnn wrote: post #51

So for each optional feature we may need three build options: 1. Force enable 2. Enable if available 3. Force disable Like, --enable_landlock=always --enable_landlock --disable_landlock

That's ... how autoconf works? If you explicitly set the enable-landlock flag, configure will fail when the feature doesn't compile.

A cmake option only has two values: ON or OFF. There is no unset. Because it is a boolean.

See: https://cmake.org/cmake/help/latest/command/option.html

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

#309

Post by eru »

worik wrote: post #306
eru wrote: post #305

Earlier quoted context omitted.

But you either make visual indentation significant, or you risk having a discrepancy between visual indentation and what the language sees.

> But you either make visual indentation significant... That would be Python. I do not like it, which does not mean it is bad, it is a matter of taste The alternative is you say "blocks are delimited by {}" `if(foo) bar` should be invalid `if(foo){bar}` is OK by me. Worik's tick of approval (Neither is valid C I think)

> That would be Python.

Not necessarily. In practice, in C-as-actually-used people (should) set up linters and formatters, so that you can rely on indentation.

When programming, this means that you can behave as if both curly braces and indentation are significant, and you get an error when they are out-of-sync.

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

#310

Post by TsiCClawOfLight »

kevincox wrote: post #258
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.

It also shows how brittle these sorts of checks are in general. I really think that this auto-disable of features based on compilation was a big mistake. It is not only very annoying when packaging things (Why does feature X not work? Because you forgot to include libY in the build environment of course) but they also fail silently even if intended. While this `.` was almost certainly malicious it is easy to imagine…

This is what the cargo/rust ecosystem does :)
Post reply on HN