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

151–160 of 322 posts

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

#151

Post by jiggawatts »

ninkendo wrote: post #76
Aeolun wrote: post #67

Earlier quoted context omitted.

I don’t know. In my code I’d always compile and check at runtime?

Some of the checks are there to tell whether or not the compiler even supports your code. You may not be able to compile your code at all, and the job of the build system is sometimes to just emit useful errors to help the person building the code to understand that they need a compiler which supports [language feature X]. Again, this is intended to be portable software. It is designed to work on lots of OS’s, with l…

> Again, this is intended to be portable software.

A scathing criticism of the OpenSSL library by the BSD team was that it was too portable in a (very real) sense that it wasn't even written in "C" any more, or targeting "libc" as the standard library. It would be more accurate to say that it was "Autotools/C" instead. By rewriting OpenSSL to target an actual full-featured libc, they found dozens of other bugs, including a bunch of memory issues other than the famous Heartbleed bug.

Platform standards like the C++ std library, libc, etc... are supposed to be the interface against which we write software. Giving that up and programming against megabytes of macros and Autotools scripts is basically saying that C isn't a standard at all, but Autotools is.

Then just admit it, and say that you're programming in the Autotools standard framework. Be honest about it, because you'll then see the world in a different way. For example, you'll suddenly understand why it's so hard to get away from Autotools. It's not because "stuff is broken", but because it's the programming language framework you and everyone else is using. It's like a C++ guy lamenting that he needs gcc everywhere and can't go back to a pure C compiler.

Job ads should be saying: "Autotools programmer with 5 years experience" instead of "C programmer". It would be more accurate.

PS: I judge languages by the weight of their build overhead in relation to useful code. I've seen C libraries with two functions that had on the order of 50kb macros to enable them to build and interface with other things.

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

#152

Post by cryptonector »

db48x wrote: post #145
Denvercoder9 wrote: post #82

Earlier quoted context omitted.

That only works for language features though, it doesn't allow detecting OS/library features.

Very true, but don’t forget that Autoconf checks for “interesting” compiler choices as well as library and OS features. And then there is libtool, which abstracts out the differences between how compilers generate shared libraries so that you only have to understand one way of doing it and it will work on all of them.

Autoconf lets you check for all sorts of things:

  - instruction set architecture
  - OS versions
  - ABIs
  - libraries (whether they are installed)
    - and what functionality they provide
  - commands/executables
  - anything you can write a macro to check
All stuff too disparate to reliably have the OS be able to answer every question you might have about it and the stuff installed on it. You can't wait for any such system to learn how to answer the questions you might have about it, so some things you can only detect, either at build configuration time, build time, or run time.

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

#153

Post by bawolff »

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…

Its weird. Like i would consider doing two unrelated backdoor-esque things in the same project really sloopy. Seems like it just significantly increases the risk of being discovered for minimal gain.

Its very confusing. Parts of this sega seem incredibly sophisticated while other parts seem kind of sloppy.

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

#154

Post by deckard1 »

eacapeisfutuile wrote: post #122
kristjansson wrote: post #117

Earlier quoted context omitted.

He had unfettered access to xz’s git?

Isn’t it a bit ironic with how much code everyone depends on that can freely be altered by some unknown party, while so much time goes into code reviews to verify internal changes at most companies.

you can have ten comments about the name of a variable, but no one bats an eye at a new npm package introduced. Also, devs that wrote code that Google depends on can't pass the leetcode gate check to get a job there.

Our industry is a laughingstock.

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

#155

Post by smashed »

josephg wrote: post #133
signa11 wrote: post #118

Earlier quoted context omitted.

compiler would perhaps "see" it ?

Sure; but so long as the compiler error is silently discarded (as it is here), the configure script will assume landlock isn't available and never use it.

A misplaced punctuation has some plausible deniability. Like the author could say he was distracted and fat fingered nonsense, honest mistake.

A utf character from a language that has zero chance of being mapped to your programmer's keyboard in the middle of a code line, that would be obvious intentional tampering or at the very least raise some eyebrows.

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

#156

Post by HideousKojima »

eacapeisfutuile wrote: post #122
kristjansson wrote: post #117

Earlier quoted context omitted.

He had unfettered access to xz’s git?

Isn’t it a bit ironic with how much code everyone depends on that can freely be altered by some unknown party, while so much time goes into code reviews to verify internal changes at most companies.

>while so much time goes into code reviews to verify internal changes at most companies

Maybe at FAANGs, but I work at a massive company and code review is non-existent.

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

#157

Post by akdev1l »

usr1106 wrote: post #143
thrtythreeforty wrote: post #6

Earlier quoted context omitted.

Fails the build, so that Landlock support is never enabled.

I don't think it fails the build. It's part of a test, trying to compile a bit of code. If it compiles the test is true and a certain feature is enabled. If the compilation fails the the feature is disabled. This is quite common in build systems. I had such a test produce incorrect results in the kernel build system recently. The problem is that the tests should really look carefully for an expected error message. If…

It fails that small build that is testing for landlock functionality. Hence it doesn’t build the support for it.

It doesn’t fail the overall build.

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

#158

Post by akdev1l »

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…

Presumably sshd itself used to lock down its own capabilities after a certain point of execution.

Removing the landlock means the daemon doesn’t lock itself down and will allow for better payload execution when they get to the exploitation stage.

I don’t think these two things are unrelated. I think they already had payloads in mind and realized this would be a hurdle.

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

#159

Post by masklinn »

SV_BubbleTime wrote: post #131
Terr_ wrote: post #119

Earlier quoted context omitted.

For those squinting, the "landlock" regular "c" is replaced with a Cyrillic U+0441.

Is there a GCC option to error on non-standard English characters?

Error-ing is the point here and what the period achieved. It’s a feature detection snippet so if it fails to compile the feature is disabled.

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

#160

Post by masklinn »

Aeolun wrote: post #64
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/

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

It’s a giant block of new code, what is it supposed to do beyond tell you it’s a giant block of new code?

Note that this is C code inside if a cmake string, even if your diff can do highlighting the odds it would highlight that are low, and if it did highlighting is generally just lexing so there wouldn’t be much to show.

Post reply on HN