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

241–250 of 322 posts

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

#241

Post by lazide »

mysidia wrote: post #198
dathinab wrote: post #189

Earlier quoted context omitted.

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

It's standard autoconf stuff, BUT... the right thing to do for a security option should be to throw an error at the configure stage If the Option is requested but can't be supported, And not to silently turn it off. That is because a human should have to Look at the build and manually make the decision to switch off a security feature from the build.

Autocomf output is so incredibly noisy though, still long odds someone would notice anytime soon.

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

#242

Post by patrakov »

kaashif wrote: post #239
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;

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.

Well, on Russian keyboards, they are on the same key.

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

#243

Post by lazide »

kristopolous wrote: post #132
Dalewyn wrote: post #127

Earlier quoted context omitted.

>How can we ensure say, that Microsoft doesn't pay someone to throw a wrench in libre office development or Adobe to sabotage Gimp? Microsoft and Adobe have reputations to uphold long into the future. Is that infallible? Hell no it isn't, but consider that Jia Tan only needed to uphold his reputation insofar as getting his backdoor onto everyone's systems. Once that is done, his reputation or the lack thereof becomes…

Those companies are famous for skullduggery. They can secure the dominance of their offering against the open source competition for well under 500k a year. It's a no brainer. What this might look like would be say, poorly discernable icons, clumsy UI design, or an unstable API that makes plugins constantly break. Large volumes of documentation that are inadequate or inaccurate in critical places, etc. If I was malic…

It would be hard for them to not get caught with their hands in the cookie jar - corp employees have high turnover, and low loyalty past their employment.

Even paying a cutout consulting company to do it would be iffy since so many finance employees would be involved in paying them, it would leak sooner than later - or at least raise a lot of questions that would be hard to answer legitimately. Being a public company, also hard to avoid auditor scrutiny.

Even a private company would have an easier time.

Nation state actors though? No such issues - that’s literally why security clearances, compartmentalization, and ‘you never really leave’ are done the way they are.

And they don’t have to worry about market blowback unless they get really excessively heavy handed (like France did in the late 80’s-90’s). They are setup to do shady stuff, it’s their raison d'etre.

[https://en.m.wikipedia.org/wiki/Industrial_espionage#:~:text....]

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

#244

Post by snazz »

eacapeisfutuile wrote: post #123
snazz wrote: post #115

Earlier quoted context omitted.

It’s similarly problematic but on a somewhat smaller scale and with fewer levels of nested dependencies.

I’m not sure this would be smaller scale? At least probably too early to tell?

I just mean fewer total packages and fewer maintainers. Linux libraries and packages don’t have the culture of making a package out of a single small function and importing it everywhere, which is part of the reason why NPM is a good case study in opportunities for supply chain attacks.

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

#245

Post by patrakov »

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?

Well - that would be exactly the point of the attacker. GCC errors out, and it does not matter whether this is because the intentionally typoed header does not exist or because non-English characters are not allowed. Errors encountered during compilation of test programs go to /dev/null anyway, as they are expected not to compile successfully on some systems - that's exactly the point of the test. So no, this option would not have helped.

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

#246

Post by delfinom »

asveikau wrote: post #80
danielhlockard wrote: post #78

Earlier quoted context omitted.

Truly seems that way currently. He said he'd really dig in starting next week and just checked his email on vacation and saw this whole mess.

It may be hard for him to re-establish trust. Maintaining xz for more than a decade then doing this would be quite a "long con" but if HN threads are any indication, many will still be suspicious. His commits on these links look legit to me. It's a sad situation for him if he wasn't involved.

Honestly, he should call it quits and just drop xz utils and move on with life. He maintained it for 15 years and struggled to get anyone else to help until Jia showed up. Meanwhile the Linux ecosystem depended on it.

The Linux ecosystem will either figure shit out and maintain it or move into a different archive library.

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

#247

Post by deanishe »

capitainenemo wrote: post #25
secstate wrote: post #24

Earlier quoted context omitted.

Mixing tabs and spaces usually throws a runtime exception. I'm not gonna make a value judgement about that, but your story doesn't make sense based on how I understand py3 Edit, sorry, shoulda read your whole commebt before replying

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.

> There's a lot of things that render as whitespace

Like what? As you note, mixing tabs and spaces is now an error.

I've never understood the objection to semantic whitespace. Complaining about having to indent code correctly strikes me as being akin to complaining about having to pee in the toilet instead of the bathtub.

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

#248

Post by SAI_Peregrinus »

raimue wrote: post #232
viraptor wrote: post #87

Earlier quoted context omitted.

Should've said function call not library call. My bad. Basically if you already have the linux/landlock.h, that should provide everything you need to do without explicit references to SYS...

Now we are running in circles. As you see in the git commit, the compile check was added because the existance of linux/landlock.h alone was not enough to check that the feature can be used. This header defines the data types for the Linux kernel interface, but not how the syscall landlock_create_ruleset(2) will be issued. That is provided by libc either as a separate wrapper function (does not exist in glibc) or the…

The only source of the claim that the existence of.linux/landlock.h is insufficient is (AFAICT) the malicious git commit. Why trust the comment, written by the attacker, to explain away a malicious change?

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

#249

Post by patrakov »

ak39 wrote: post #228
Aurornis wrote: post #5

Earlier quoted context omitted.

The function is “check_c_source_compiles”. The comment indicates that the intention is to confirm that the Landlock functionality can be compiled on the system, in which case it will be enabled. The stray dot isn’t valid C, so it will never compile. By ensuring it can never compile, Landlock will never be enabled.

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 recent enough? You can't fail a unit test just because the software is being compiled on an old but still supported system, so it would be a "SKIPPED" result at best, which is not a failure and which is not normally caught.

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

#250

Post by Rexxar »

yread wrote: post #202
kristopolous wrote: post #132

Earlier quoted context omitted.

Those companies are famous for skullduggery. They can secure the dominance of their offering against the open source competition for well under 500k a year. It's a no brainer. What this might look like would be say, poorly discernable icons, clumsy UI design, or an unstable API that makes plugins constantly break. Large volumes of documentation that are inadequate or inaccurate in critical places, etc. If I was malic…

1. Identify particularly unproductive employees. The people who relly muck things up. 2. Make them contribute to a competing open source project. 3. Profit!

3. Discover the employee was not unproductive because he was bad but because of internal bureaucracy
Post reply on HN