Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Backdoor in upstream xz/liblzma leading to SSH server compromise

openwall.com

Post reply on HN
Print view View original

371–380 of 1001 posts

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#371

Post by bananapub »

b112 wrote: post #43
agwa wrote: post #8

> openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma. The systemd notification protocol could have been as simple as just writing a newline to a pipe, but instead you have to link to the libsystemd C library, so now security-critical daemons like openssh have additional dependencies like liblzma loaded…

One of the objections that many people do not understand, is that systemd adds complexity. Unnecessary complexity. Boats full, loads full, mountains full of complexity. Yes, there are things delivered with that complexity. However, as an example, sysvinit is maybe, oh, 20k lines of code including binaries, heck including all core init scripts. What's systemd? 2M lines? It was >1M lines 4+ years ago. For an init syste…

> One of the objections that many people do not understand, is that systemd adds complexity. Unnecessary complexity. Boats full, loads full, mountains full of complexity.

this is and always has been such a dumb take.

if you'd like to implement an init (and friends) system that doesn't have "unnecessary complexity" and still provides all the functionality that people currently want, then go and do so and show us? otherwise it's just whinging about things not being like the terrible old days of init being a mass of buggy and racey shell scripts.

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#372

Post by msm_ »

jcalvinowens wrote: post #278

Oof, this is on my Sid laptop: {0}[calvinow@mozart ~] dpkg-query -W liblzma5 liblzma5:amd64 5.6.0-0.2 {0}[calvinow@mozart ~] hexdump -ve '1/1 "%.2x"' /lib/x86_64-linux-gnu/liblzma.so.5 | grep -c f30f1efa554889f54c89ce5389fb81e7000000804883ec28488954241848894c2410 1 Glad I stopped running sshd on my laptop a long time ago... still probably going to reinstall :/

No obvious need to reinstall if you didn't use ssh and expose it publicly and are not a politically important person. All signs suggest that it was a nation state attack, and you are likely not a target.

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#373

Post by londons_explore »

bawolff wrote: post #318
ncr100 wrote: post #258

Earlier quoted context omitted.

Security Researchers : Is this request-for-private-disclosure + "90-days before public" reasonable? It's a SEVERE issue, to my mind, and 90 days seems too long to me.

Whether its reasonable is debatable, but that type of time frame is pretty normal for things that aren't being actively exploited. This situation is perhaps a little different as its not an accidental bug waiting to be discovered but an intentionally placed exploit. We know that a malicious person already knows about it.

If you were following Google Project Zero's policy (which many researchers do), any in-the-wild exploits would trigger an immediate reveal.

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#374

Post by isbvhodnvemrwvn »

zeroCalories wrote: post #333
port443 wrote: post #313

I think its much more likely this was not a bad actor, given their long history of commits. It's a known fact that China will "recruit" people to operate them. A quote: > They talk to them, say my friend, I see you like our special menu. Are you from China? Are you here on a VISA? Do you have family back there? Would you like your family to stay alive? Is your loyalty to this temporary employer or is your loyalty to…

I think we should seriously consider something like a ts clearance as mandatory for work on core technologies. Many other projects, both open and closed, are probably compromised by foreign agents.

This only ensures the backdoors are coming from governments that issued the clearances, nothing more. I prefer more competition, at least there is incentive to detect those issues.

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#377

Post by junon »

5kg wrote: post #146
AdmiralAsshat wrote: post #52

Yikes! Do you have any info on the individual's background or possible motivations?

There is zero web presence for this person and associated email address. Looks more likely a fake identity than compromised account.

This is all I can find on them.

    carrd.co jiat0218@gmail.com business https://jiat0218@gmail.com.carrd.co
    eBay JiaT75 shopping https://www.ebay.com/usr/JiaT75
    giters jiat0218 coding https://giters.com/jiat0218
    giters JiaT75 coding https://giters.com/JiaT75
    GitHub jiat0218 coding https://github.com/jiat0218
    GitHub JiaT75 coding https://github.com/JiaT75
    Mastodon-meow.so.. jiat0218@gmail.com social https://meow.social/@jiat0218@gmail.com
Beyond that, nothing surefire. (This is all publicly queryable information, if anyone is curious).

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#378

Post by 5p4n911 »

blcknight wrote: post #158
bonyt wrote: post #48

For those panicking, here are some key things to look for, based on the writeup: - A very recent version of liblzma5 - 5.6.0 or 5.6.1. This was added in the last month or so. If you're not on a rolling release distro, your version is probably older. - A debian or RPM based distro of Linux on x86_64. In an apparent attempt to make reverse engineering harder, it does not seem to apply when built outside of deb or rpm p…

> Debian testing already has a version called '5.6.1+really5.4.5-1' that is really an older version 5.4, repackaged with a newer version to convince apt that it is in fact an upgrade. I'm surprised .deb doesn't have a better approach. RPM has epoch for this purpose http://novosial.org/rpm/epoch/index.html

I really like the XBPS way of the reverts keyword in the package template that forces a downgrade from said software version. It's simple but works without any of the troubles RPM epochs have with resolving dependencies as it's just literally a way to tell xbps-install that "yeah, this is a lower version number in the repository but you should update anyway".

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#379

Post by jcalvinowens »

msm_ wrote: post #372
jcalvinowens wrote: post #278

Oof, this is on my Sid laptop: {0}[calvinow@mozart ~] dpkg-query -W liblzma5 liblzma5:amd64 5.6.0-0.2 {0}[calvinow@mozart ~] hexdump -ve '1/1 "%.2x"' /lib/x86_64-linux-gnu/liblzma.so.5 | grep -c f30f1efa554889f54c89ce5389fb81e7000000804883ec28488954241848894c2410 1 Glad I stopped running sshd on my laptop a long time ago... still probably going to reinstall :/

No obvious need to reinstall if you didn't use ssh and expose it publicly and are not a politically important person. All signs suggest that it was a nation state attack, and you are likely not a target.

We'll see... given that sshd is just one of many possible argv[0] it may have choosen to act on, I'm going to be a little paranoid until it's been fully analyzed. It just takes half an hour to reinstall, I have some shows to catch up on anyway :)

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#380

Post by bananapub »

gopher_space wrote: post #152
eigenvalue wrote: post #129

Earlier quoted context omitted.

Every single commit this person ever did should immediately be rolled back in all projects.

It's weird and disturbing that this isn't the default perspective.

it's not weird at all?

randomly reverting two years of things across dozens of repositories will break them, almost definitely make them unbuildable, but also make them unreleasable in case any other change needs to happen soon.

all of their code needs to be audited to prove it shouldn't be deleted, of course, but that can't happen in the next ten minutes.

I swear that HN has the least-thought-through hot takes of any media in the world.

Post reply on HN