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

311–320 of 322 posts

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

#311

Post by kevincox »

BobbyTables2 wrote: post #307
kevincox wrote: post #259

Earlier quoted context omitted.

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.

I think most distributions use some sort of build sandboxing at this point to avoid this problem and increase reproducibility in general right?

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

#312

Post by xorcist »

snnn wrote: post #308
xorcist wrote: post #298

Earlier quoted context omitted.

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

Right, but the boolean is set by an autoconf script, is it not?

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

#313

Post by nebulous1 »

bschwindHN wrote: post #299
patrakov wrote: post #114

Earlier quoted context omitted.

Even more evil would have been to replace this line (void)SYS_landlock_create_ruleset; with this: (void)SYS_landloсk_create_ruleset;

Another point where I appreciate the Rust compiler: warning: the usage of Script Group `Cyrillic` in this crate consists solely of mixed script confusables --> src/lib.rs:1:4 | 1 | fn SYS_landloсk_create_ruleset() { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: the usage includes 'с' (U+0441) = note: please recheck to make sure their usages are indeed what you want = note: `#[warn(mixed_script_confusables)]` on by default…

The character was in a string, not directly in what was being compiled. The contents of the string failing to compile was the point, as landlock was then disabled.

From what I understand, this landlock disabling wasn't relevant to the sshd attack. It appears it was setting up for something else.

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

#314

Post by Cloudef »

kevincox wrote: post #311
BobbyTables2 wrote: post #307

Earlier quoted context omitted.

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.

I think most distributions use some sort of build sandboxing at this point to avoid this problem and increase reproducibility in general right?

Im not aware anything else than nix and guix. Perhaps other distros build in dedicated vms / containers.

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

#315

Post by itsTyrion »

cocoa19 wrote: post #265
kaashif wrote: post #239

Earlier quoted context omitted.

With the . the author can claim it was unintentional. It's impossible (or at least very hard) to claim the Cyrillic c is unintentional. To me, that makes the . more evil.

Plausible deniability

also applies for c/с - the с (Cyrillic s) is on the same key as the Latin c on a Russian keyboard. bottom row starts with zxc/ячс respectively.

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

#316

Post by account42 »

Terr_ wrote: post #276
pajko wrote: post #210

Earlier quoted context omitted.

Probably the code review tools should be hardened as well, to indicate if extended identifiers had been introduced to a line where there wasn't any. That would help catching the replacement of a 'c' character with a Russian one. Btw, the -fno-extended-identifiers compiler parameter gives an error if UTF-8 identifiers are used in the code: :3:11: error: stray '\317' in program float = 0.5f;

> Probably the code review tools should be hardened as well, to indicate if extended identifiers had been introduced to a line where there wasn't any. Maybe in the future more languages/ tools will have the concept of per-project character sets, as opposed to trying to wrangle all possible Unicode ambiguity problems. I suppose then the problem is how to permit exceptions when integrating with some library written in…

Or we could just accept English as the lingua franca of computing and not try to support anything other than ASCII in source code (at least not outside string constants). That way not only do we eliminate a whole class of possible exploits but also widen the number of people who can understand the code and spot issues.

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

#317

Post by account42 »

fweimer wrote: post #188
SV_BubbleTime wrote: post #131

Earlier quoted context omitted.

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

> But it may block some characters which are used in standard English

So what? Source code was fine with ASCII for a long time, this push for unicode symbols is a recent endeavor and IMO a huge mistake not just because of the security impliciations.

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

#318

Post by account42 »

dilyevsky wrote: post #293
kaashif wrote: post #280

Earlier quoted context omitted.

Good point - it might be plausible if the author actually were Russian, but they aren't.

Or are they?

Even someone provably not russian can just claim that they were learning the language (or a different one that also uses cyrillic).

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

#319

Post by account42 »

tsimionescu wrote: post #177
mewpmewp2 wrote: post #85

Earlier quoted context omitted.

I think main issue was that it was embedded in the file itself like that. Would have preferred to have it in a separate valid C file with syntax highlighting etc and being parsed from that file.

Perhaps, but given how most build systems work, that would complicate things in other ways (since build systems often try to compile all .c files).

That's really not how most build systems work.

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

#320

Post by account42 »

patrakov wrote: post #249
ak39 wrote: post #228

Earlier quoted context omitted.

Shouldn't there be a unit test to confirm landlock is on/off? (I mean, this seems a crucial aspect of the code which needs 100% test coverage.)

This is not something that a unit test can catch. First, this 100% coverage rule applies to the program/library code, and only to the subset that is not ifdeffed out (otherwise, you will not be able to have, e.g., Windows-specific code), and definitely not to the build system's code. Second, how would you test that landlock works, in a unit test, when this feature is optional and depends on the system headers being r…

The proper way would be to have a minimum glibc version (or whatever it depends on) where you expect landlock to be available and then shout loudly if it is not so that you can either fix the check or correct your expectations. This isn't just for malicious users, these checks can be brittle enough that a small change in the library or even compiler update can occasionally break something. Of course this is ideal and does not match common practice. I can't even claim of doing this consistently myself although I did start that practice before this mess.
Post reply on HN