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

181–190 of 322 posts

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

#181

Post by CGamesPlay »

chilling wrote: post #138
CGamesPlay wrote: post #93

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!)

I hear this stuff for the first time, can you post some info about that?

Like in this article, we have a patch that introduces a security flaw (disabling landlock). We later have a patch that fixes it, specifically. The job of the LLM is to reproduce the fixing patch given the problem patch. Or at the very least, explain that this patch results in landlock always being disabled. To be clear, this problem is much, much harder than the problems LLMs are solving now, requiring knowledge of autotools behavior that isn’t included in the context (identifying that a failed build disables the feature, and that this build always fails).

There was another example where this team submitted a patch that swapped safe_fprintf for fprintf while adding some additional behavior. It was later pointed out that this allows printing invisible characters to the stream, which allows hiding some of the files that are placed when decompressing.

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

#182

Post by MrDresden »

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

The point still stands that this is an inherit possibility in the language it self.

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

#183

Post by usr1106 »

akdev1l wrote: post #158
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.

It's pretty impossible to lock down sshd. The restrictions are inherited by all ancestors. What would the sysadmin say if they find themselves in a restricted shell?

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

#184

Post by tsimionescu »

jiggawatts wrote: post #151
ninkendo wrote: post #76

Earlier quoted context omitted.

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, inclu…

C basically has no standard library. It's no surprise to anyone who has ever used it more than in passing that you depend on the chosen build system to replace that. Building portable C libraries is very different because of this from any other commonly used programming language - even C++.

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

#185

Post by leni536 »

Optional features should not depend on feature detection, ever. Feature detection for a security feature should be suspicious, even if it works as intended.

Optional features should always be configured by whoever tries to compile the code. There can be defaults, but they shouldn't depend on the environment.

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

#186

Post by eru »

MrDresden wrote: post #182
_visgean wrote: post #39

Earlier quoted context omitted.

Never had this happen, this is largely eliminated by using tools like black or other autoformatters.

The point still stands that this is an inherit possibility in the language it self.

Well, in C the visual indentation and the meaning of the code (given by {}) can diverge. That's even worse, and happens in practice. Many style guidelines for C have evolved specifically to address that problem with 'the language itself'.

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

#187

Post by astrange »

masklinn wrote: post #161
astrange wrote: post #142

Earlier quoted context omitted.

configure would print that it's not enabled, so it seems like the kind of thing people would eventually notice.

Maybe, eventually, but how many people read the reams of garbage autoconf spouts out until the feature they wanted fails to materialize?

I used to and it's actually how I got a large part of my computer skills, but unfortunately I got medicated for ADHD and became normal and can't do it anymore.

But I still think reading boring logs is a great way to understand a system. Turning on all the intermediates for a compiler (llvm ghc etc) is very educational too.

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

#188

Post by fweimer »

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?

The -fno-extended-identifiers option seems to do something in this area, but I don't know if it is sufficient. But it may block some characters which are used in standard English (for some values of standard).

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

#189

Post by dathinab »

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.

It's also iffy tbh. that the compilation check functionality:

- doesn't force users to differentiate between syntax errors and other errors (e.g. symbols not found). Partially you can't even make it work properly if you want due to C macros.

- it seems sensible, tbh. if "does compile" checks for compatibility seems sensible then there is so much wrong with the ecosystem in so many ways

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

#190

Post by Nezghul »

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.

That "check_c_source_compiles" function should first test if the provided code snipped is "valid C code in general" and only then check if it compiles in given system.
Post reply on HN