3 ms·
In addition… if your build system has things like this as OK: > xz -dc $top_srcdir/tests/files/$p | eval $i | LC_ALL=C sed "s/\(.\)/\1\n/g" | LC_ALL=C awk 'BEG
by SV_BubbleTime 3y ago
In addition… if your build system has things like this as OK:
> xz -dc $top_srcdir/tests/files/$p | eval $i | LC_ALL=C sed "s/\(.\)/\1\n/g" | LC_ALL=C awk 'BEGIN{FS="\n";RS="\n";ORS="";m=256;for(i=0;i<m;i++){t[sprintf("x%c",i)]=i;c[i]=((i*7)+5)%m;}i=0;j=0;for(l=0;l<8192;l++){i=(i+1)%m;a=c[i];j=(j+a)%m;c[i]=c[j];c[j]=a;}}{v=t["x" (NF<1?RS:$1)];i=(i+1)%m;a=c[i];j=
You should probably expect the potential for abuse?
We’re moving towards complexity that is outpacing human ability for any one person to understand, explain, and thus check an entire object.
And for what? Build efficiency? Making a “trick” thing? When was the project ever going to go back and make things simpler? (Never)
- necubi 3y agoI’m not sure why you’d say that we’re “moving towards” this sort of build system complexity. This is 1990s autoconf bs that has not yet been excised from the Linux ecosystem. Every modern build system, even the really obtuse ones, are less insane than autoconf. And the original purpose of this was not for efficiency, but to support a huge variety of target OSes/distros/architectures, most of which are no longer used in any real capacity.
- ibotty 3y agoThis is not part of autotools output. This is part of the backdoor. Not arguing about autotools drawbacks though.
- SV_BubbleTime 3y ago> has not yet been excised from the Linux ecosystem That is my point. I should have written allows and not has.
- pelasaco 3y agoI think the point is: In code reviews, if you see a blob like that you would ask for more information. Me as lead developer, I go every monday through all commits on master, and PRs pushed in the last days, because I unfortunately cannot review every single PR, but I delegate it to the team.. nevertheless, Monday, I review the last week commits.. Quite funny that it didn't raise any attention. One can say: "right, its open source, people do it in their free time", ok, fine, but not the people working for SUSE, which for instance allowed this code reach their packages, even though they have multiple review steps there..
- mrb 3y agoTo be clear: the build system did not use the code fragment you quoted. This complex awk code is a later stage of the backdoor.
- SV_BubbleTime 3y agoI see, my point was more than this shouldn’t be allowed. I think part of the problem with a lot of things is we’re allowing complexity for the sake of complexity. No one has simplicity-required checks. My previous post should say “allows things like this”.
- zaroth 3y agoUnless I’m misunderstanding, all this code was embedded and hidden inside the obfuscated test files. None of this would have been visible in commits or diffs at all.
- mrb 3y agoBut what are you suggesting exactly? The code fragment you quoted was awk code. Awk is a generic programming language. Any programming language can be written to be complex and unreadable.
- pelasaco 3y ago> Any programming language can be written to be complex and unreadable. The question is you as lead developer, reviewing a commit with a complex and unreadable code snippet, what would you do?
- edflsafoiewq 3y agoYou would reject it of course, which is exactly why this code never appeared in a commit. The stage 0 of the exploit was not checked in, but directly added to the autogenerated build script in the release tarball, where, even if someone did review the script, it looks plausibly like other autogenerated build gunk. The complex and unreadable scripts in the further stages were hidden inside binary test files, so no one reviewing the commit that added them (https://git.tukaani.org/?p=xz.git;a=commit;h=cf44e4b https://git.tukaani.org/?p=xz.git;a=commit;h=cf44e4b) would directly see that code.