I bet that you use software packages that are built and authored on systems that have systemd+sshd, though.
What happens if development or build machines belong to people who control projects that you trust and have been compromised?
Do you use a web browser? Do you use a graphical desktop environment? Are the machines those guys use vulnerable? Are the developers of the libraries that they depend on vulnerable?
Remember, this guy was attacking a downstream project (sshd) by compromising and signing source in a specific tarball of a library – the malicious code never made it into git – used by an unrelated piece of software (systemd) that some distros, not even the ssh guys, happened to link into sshd’s memory space. He’s trying to compromise unrelated software via elaborate supply chain attacks.
Andrew (and anyone else), please do not take this code right now.
Until the backdooring of upstream xz[1] is fully understood, we should not
accept any code from Jia Tan, Lasse Collin, or any other folks associated
with tukaani.org. It appears the domain, or at least credentials
associated with Jia Tan, have been used to create an obfuscated ssh
server backdoor via the xz upstream releases since at least 5.6.0.
Without extensive analysis, we should not take any associated code.
It may be worth doing some retrospective analysis of past contributions
as well…
At the time I thought it was just rude, but maybe this is when it all started.
I don’t know how many open-source project maintainers would be on guard for something that subtle, people coordinating to take over maintainership of a project.
I mean, xz isn’t normally something you’d immediately think of as security-critical. I doubt that a maintainer knows or thinks about about all the potential downstream dependencies (in this case, not even a standard sshd depedendency, but one that came up because of a patch that Debian used to add some systemd functionality).
EDIT:
I mean, xz isn’t normally something you’d immediately think of as security-critical.
On second thought, it actually is, given that Debian packages are xz-compressed.
And for a state sponsored attacker is cheaper to bribe (or threaten to kill, even cheaper) the single developer to add a backdoor than all the research to find a zero day
We’ve had a lot of trust among open-source projects, where people just kind of assume that people are doing the right thing, but there are some very, very large places where a potential attacker might manage to get maintainership of a library, if they’re willing to spend a long time slowly getting access.
I’d figured that one day, we’d have a really big apocalypse that would cause some of that to break down, and we’d lose our innocence and have to do things differently.
I mean, let’s say that I’m an important security researcher, and I use R, a common statistical tool, nothing directly to do with security. That pulls in all kinds of libraries from various online statistics archives, and the people working on those aren’t really security people, probably generally don’t know how to vet things effectively even if they wanted to do so. Perl and Python and other tools have similar things. If someone can target that security researcher using that, could be nothing more than an intentionally-induced parsing bug in a library they use, then they can get things like that researcher’s private keys, maybe get ahold of signing keys for software packages and the like.
And in the xz case, it looks like social engineering efforts were used against both the maintainer and packagers. The open-source community has a lot of well-meaning strangers collaborating in good faith, built on a lot of trust extended, and they aimed to exploit that.
All of the problems get a lot harder to deal with when it’s someone willing to spend a lot of time and use sophisticated tactics.
In case, like me, you were wondering what this has to do with ssh:
openssh does not directly use liblzma. However debian and several other
distributions patch openssh to support systemd notification, and libsystemd
does depend on lzma.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.
Rules:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
Wow… Luckly I don’t use systemd which seems to be the vector causing the sshd backdoor, via liblzma…
Pretty scary anyway.
I bet that you use software packages that are built and authored on systems that have systemd+sshd, though.
What happens if development or build machines belong to people who control projects that you trust and have been compromised?
Do you use a web browser? Do you use a graphical desktop environment? Are the machines those guys use vulnerable? Are the developers of the libraries that they depend on vulnerable?
Remember, this guy was attacking a downstream project (sshd) by compromising and signing source in a specific tarball of a library – the malicious code never made it into git – used by an unrelated piece of software (systemd) that some distros, not even the ssh guys, happened to link into sshd’s memory space. He’s trying to compromise unrelated software via elaborate supply chain attacks.
There’s talk on the Linux kernel mailing list. The same person made recent contributions there.
Man, there is a lot of concerning stuff there.
In particular, one person commented that the original xz maintainer was possibly subjected to a pressure campaign to hand over maintainership.
I don’t know how many open-source project maintainers would be on guard for something that subtle, people coordinating to take over maintainership of a project.
I mean, xz isn’t normally something you’d immediately think of as security-critical. I doubt that a maintainer knows or thinks about about all the potential downstream dependencies (in this case, not even a standard sshd depedendency, but one that came up because of a patch that Debian used to add some systemd functionality).
EDIT:
On second thought, it actually is, given that Debian packages are xz-compressed.
Wow
And for a state sponsored attacker is cheaper to bribe (or threaten to kill, even cheaper) the single developer to add a backdoor than all the research to find a zero day
We’ve had a lot of trust among open-source projects, where people just kind of assume that people are doing the right thing, but there are some very, very large places where a potential attacker might manage to get maintainership of a library, if they’re willing to spend a long time slowly getting access.
I’d figured that one day, we’d have a really big apocalypse that would cause some of that to break down, and we’d lose our innocence and have to do things differently.
I mean, let’s say that I’m an important security researcher, and I use R, a common statistical tool, nothing directly to do with security. That pulls in all kinds of libraries from various online statistics archives, and the people working on those aren’t really security people, probably generally don’t know how to vet things effectively even if they wanted to do so. Perl and Python and other tools have similar things. If someone can target that security researcher using that, could be nothing more than an intentionally-induced parsing bug in a library they use, then they can get things like that researcher’s private keys, maybe get ahold of signing keys for software packages and the like.
And in the xz case, it looks like social engineering efforts were used against both the maintainer and packagers. The open-source community has a lot of well-meaning strangers collaborating in good faith, built on a lot of trust extended, and they aimed to exploit that.
All of the problems get a lot harder to deal with when it’s someone willing to spend a lot of time and use sophisticated tactics.
A good summary here: https://arstechnica.com/security/2024/03/backdoor-found-in-widely-used-linux-utility-breaks-encrypted-ssh-connections/
In case, like me, you were wondering what this has to do with ssh: