this post was submitted on 01 Apr 2024
1195 points (99.3% liked)

Linux

55760 readers
1234 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 6 years ago
MODERATORS
 
(page 2) 50 comments
sorted by: hot top controversial new old
[–] luthis@lemmy.nz 20 points 1 year ago (12 children)

I have heard multiple times from different sources that building from git source instead of using tarballs invalidates this exploit, but I do not understand how. Is anyone able to explain that?

If malicious code is in the source, and therefore in the tarball, what's the difference?

[–] harsh3466@lemmy.ml 14 points 1 year ago* (last edited 1 year ago) (3 children)

I don’t understand the actual mechanics of it, but my understanding is that it’s essentially like what happened with Volkswagon and their diesel emissions testing scheme where it had a way to know it was being emissions tested and so it adapted to that.

The malicious actor had a mechanism that exempted the malicious code when built from source, presumably because it would be more likely to be noticed when building/examining the source.

Edit: a bit of grammar. Also, this is my best understanding based on what I’ve read and videos I’ve watched, but a lot of it is over my head.

[–] Corngood@lemmy.ml 16 points 1 year ago

it had a way to know it was being emissions tested and so it adapted to that.

Not sure why you got downvoted. This is a good analogy. It does a lot of checks to try to disable itself in testing environments. For example, setting TERM will turn it off.

[–] arthur@lemmy.zip 13 points 1 year ago (1 children)

The malicious code is not on the source itself, it's on tests and other files. The building process hijacks the code and inserts the malicious content, while the code itself is clean, So the co-manteiner was able to keep it hidden in plain sight.

[–] sincle354@kbin.social 6 points 1 year ago (1 children)

So it's not that the Volkswagen cheated on the emissions test. It's that running the emissions test (as part of the building process) MODIFIED the car ITSELF to guzzle gas after the fact. We're talking Transformers level of self modification. Manchurian Candidate sleeper agent levels of subterfuge.

load more comments (1 replies)
[–] WolfLink@lemmy.ml 10 points 1 year ago

The malicious code wasn’t in the source code people typically read (the GitHub repo) but was in the code people typically build for official releases (the tarball). It was also hidden in files that are supposed to be used for testing, which get run as part of the official building process.

[–] Subverb@lemmy.world 7 points 1 year ago* (last edited 1 year ago)

The malicious code was written and debugged at their convenience and saved as an object module linker file that had been stripped of debugger symbols (this is one of its features that made Fruend suspicious enough to keep digging when he profiled his backdoored ssh looking for that 500ms delay: there were no symbols to attribute the cpu cycles to).

It was then further obfuscated by being chopped up and placed into a pure binary file that was ostensibly included in the tarballs for the xz library build process to use as a test case file during its build process. The file was supposedly an example of a bad compressed file.

This "test" file was placed in the .gitignore seen in the repo so the file's abscense on github was explained. Being included as a binary test file only in the tarballs means that the malicious code isn't on github in any form. Its nowhere to be seen until you get the tarball.

The build process then creates some highly obfuscated bash scripts on the fly during compilation that check for the existence of the files (since they won't be there if you're building from github). If they're there, the scripts reassemble the object module, basically replacing the code that you would see in the repo.

Thats a simplified version of why there's no code to see, and that's just one aspect of this thing. It's sneaky.

load more comments (10 replies)
[–] etchinghillside@reddthat.com 17 points 1 year ago (14 children)

Any additional information been found on the user?

[–] underisk@lemmy.ml 12 points 1 year ago* (last edited 1 year ago)

as long as you're up to date on everything here: https://boehs.org/node/everything-i-know-about-the-xz-backdoor

the only additional thing i've seen noted is a possibilty that they were using Arch based on investigation of the tarball that they provided to distro maintainers

load more comments (13 replies)
load more comments
view more: ‹ prev next ›