Thanks the simplified explanation and noisy image comparison is quite appreciated. It gives me a good grasp of what people mean by the sophistication involved.
I also saw a comment on reddit mentioning that the "sandboxing" method was sabotaged with a dot. It's on the line just after "#include <sys/prctl.h>" you can see a dot all the way on the left.
They could have just misspelt one of the constants. Even less obvious and more deniable.
There's multiple things like this in this backdoor that seems like they've been super sneaky (using a compile check to disable Landlock is genius) but then half-assed the last step.
I really hate writing these compile/build time conditional things. It's hard to have tests that it's enabled when it should be and disabled when it isn't, especially if it's in the build system where there's no unit test framework.
And that's with the failure party being just accidentally borking it so the test always fails or always succeeds when it shouldn't. You can see why it's a juicy target for malicious actions.
This is very likely just a mistake and not deliberate.
a) absolutely nobody uses cmake to build this packet
b) if you try to build the packet with cmake and -DENABLE_SANDBOX=landlock, the build just fails: https://i.imgur.com/7xbeWFx.png
The "." does not disable sandboxing, it just makes it impossible to build with cmake. If anyone had ever actually tried building it with cmake, they would get the error and realize that something is wrong. It makes absolutely no sense that this would be malicious attempt to reduce security.
I also saw a comment on reddit mentioning that the "sandboxing" method was sabotaged with a dot. It's on the line just after "#include <sys/prctl.h>" you can see a dot all the way on the left.
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2...
https://old.reddit.com/r/linux/comments/1brhlur/xz_utils_bac...