Posts Tagged ‘Git’

Does Malicious Backdoor Compromise SSH?

Monday, April 1st, 2024

A newly discovered backdoor found in the xz liblzma library of XZ Utils, the XZ format compression utilities included in most Linux distributions, targets the RSA implementation of OpenSSH.

For those outside of tech, that sentence was an unreadable jumble of acronyms. For those inside tech, a chill probably ran down their spine, as those technologies are everywhere. Anytime anyone buys something online, they’re going to be using SSH to create a secure channel to pass transaction information. [As a commenter noted, SSH is a command tool rather than Secure Socket Layer (SSL), which is used for encrypted transactions. Mental typo. My bad. – LP.] Depending on how many distros are using that library, the consequence range from “bad” to “really, really bad.”

Details:

A vulnerability (CVE-2024-3094) in XZ Utils, the XZ format compression utilities included in most Linux distributions, may “enable a malicious actor to break sshd authentication and gain unauthorized access to the entire system remotely,” Red Hat warns.

The cause of the vulnerability is actually malicious code present in versions 5.6.0 (released in late February) and 5.6.1 (released on March 9) of the xz libraries, which was accidentally found by Andres Freund, a PostgreSQL developer and software engineer at Microsoft.

“After observing a few odd symptoms around liblzma (part of the xz package) on Debian sid installations over the last weeks (logins with ssh taking a lot of CPU, valgrind errors) I figured out the answer: The upstream xz repository and the xz tarballs have been backdoored,” he shared via the oss-security mailing list.

According to Red Hat, the malicious injection in the vulnerable versions of the libraries is obfuscated and only included in full in the download package.

“The Git distribution lacks the M4 macro that triggers the build of the malicious code. The second-stage artifacts are present in the Git repository for the injection during the build time, in case the malicious M4 macro is present,” they added.

“The resulting malicious build interferes with authentication in sshd via systemd.”

I’m just going to note for the record that a whole lot of longtime Linux programmers absolutely hated the introduction of systemd. I don’t have deep enough Linux chops to take a side in this controversy, or know whether systemd was a significant factor in allowing the exploit to work.

Moving on:

The malicious script in the tarballs is obfuscated, as are the files containing the bulk of the exploit, so this is likely no accident.

“Given the activity over several weeks, the committer is either directly involved or there was some quite severe compromise of their system. Unfortunately the latter looks like the less likely explanation, given they communicated on various lists about the “fixes” [for errors caused by the injected code in v5.6.0],” Freund commented.

One silver lining is that the problem doesn’t look to be as widespread as it could be.

“Luckily xz 5.6.0 and 5.6.1 have not yet widely been integrated by Linux distributions, and where they have, mostly in pre-release versions.”

Red Hat says that the vulnerable packages are present in Fedora 41 and Fedora Rawhide, and have urged users of those distros to immediately stop using them.

“If you are using an affected distribution in a business setting, we encourage you to contact your information security team for next steps,” they said, and added that no versions of Red Hat Enterprise Linux (RHEL) are affected.

Since Red Hat is usually the default for big E-commerce platforms, it looks like this exploit is merely “bad” rather than “really, really bad,” which means its not nearly as bad as, say, Log4J was. Your Amazons and eBays are probably safe from the exploit.

The people who are likely going to be hurt by this exploit are mom and pop E-commerce sites using their webhost’s “build an E-commerce site using these easy tools” feature. The smaller the site, the more likely they’re using a free distro, some of which may have this vulnerability.

Whatever the site, they should run an updated software composition analysis tool on stacks and build-chains to see if they’re vulnerable.

rm -rf .github

Tuesday, February 16th, 2016

Git, if you are unfamiliar with it, is a software source control program, allowing you to check code (and other things; I’ve used it for documentation) in and out of a repository, which can be either local or remote.

GitHub is (for now) the most popular remote repository for Git. You can either put all your code in a public repository for free, or in a private repository for a modest per-user fee. GitHub makes its money off bells and whistles for private repositories.

Now comes word that GitHub’s “Social Impact Team” has decided “We don’t want any of those stinking white people here.” “It is very hard to even interview people who are ‘white’ which makes things challenging.”

Git and GitHub got to be where they are today because they’re both free-ish, but also because they’re deeply beloved of open source programmers not deterred by the steep learning curve of Git’s command-line-fu. But open source programmers, in addition to being distinctly pale of hue on average, tend to hate Social Justice Warrior types, if the comments on the SJW threads the “new” Slashdot keeps trying to cram down their reader’s throats on a regular basis is any indication.

Since Git (the program) isn’t limited to any particular repository, it’s fairly easy (remembering, always, that everything about Git falls into two general categories: trivial (because you’ve memorized and mastered the syntax) and impossible (because you haven’t)) to move your existing code to a new repository. And there are plenty of GitHub competitors, including a new one from Google.

No wonder GitHub is suffering an exodus of talent…

(Hat tip: Moe Lane.)