The xz sshd backdoor rabbithole goes quite a bit deeper • Hacker News Board

Re: The xz sshd backdoor rabbithole goes quite a bit deeper

#261

Post by cesarb » Sun, Apr 07, 2024, 8:12 PM UTC

anarazel wrote: post #252

cesarb wrote: post #162

Earlier quoted context omitted.

From what I understand, it wasn't even the performance testing itself that caught the backdoor. The developer wanted to have the machine as quiescent as possible (so that nothing else running on it would interfere) before starting the performance tests, but sshd was using much more CPU than expected (and this could be observed with simple tools like "top"). My guess is that the usual "backscatter" of password guessin…

Nearly spot on. I indeed was seeing sshd usage via top. > but the backdoor made each login attempt use a significant amount of CPU time to check whether it was an encrypted request from the attacker Absurdly enough, the high cpu usage is well before it even tries to figure that out. Due to avoiding "suspicious" strings in both the binary and memory, it has a more expensive string matching routine. Finding all the sym…

> Unfortunately not. It's a machine I have at home, with some port of my public IP redirected to it, as I often need it when not at home.

Wow, that must have really sucked. It's one thing to have a rented office downtown (a VPS or similar) be backdoored, but to find a burglar broke into your home while it was under construction (or renovation in case it was a distro upgrade) and added a secret passage to it from the outside? What else did the burglar mess with while you weren't looking?

> Oddly enough, my threat model did not include getting attacked with something as sophisticated as this, so I thought that was fine (only pubkey, no root).

Most people's threat model is "everything except sshd is risky; openssh is from these cool paranoid people at OpenBSD and, as long as nobody can password guess, it's safe from non-authenticated attackers". That is, often sshd is the only open port (which helps explain why the attacker fixated on it).

Re: The xz sshd backdoor rabbithole goes quite a bit deeper

#262

Post by timschmidt » Sun, Apr 07, 2024, 8:54 PM UTC

ilvez wrote: post #131

ericpruitt wrote: post #104

Earlier quoted context omitted.

> Is not possible the attacker simply took over the account of some one genuinely getting involved in the community either hacked or just with $5 wrench and then committed the malicious code ? Given the behavior of the accounts that applied pressure on the original xz maintainer, this seems unlikely to me.

Or they just bought the guy at one point, because I understood the malicious behaviour started quite recently.

Jia Tan's very first commit two years ago made suspicious changes to liblzma. See the timeline here: https://boehs.org/node/everything-i-know-about-the-xz-backdo...

Re: The xz sshd backdoor rabbithole goes quite a bit deeper

#263

Post by qarl » Sun, Apr 07, 2024, 8:56 PM UTC

samus wrote: post #223

qarl wrote: post #137

Earlier quoted context omitted.

You're discussing it.

We are all speculating .

So this whole thread is based on the premise that the OP was using the formal definition of "discuss" rather than the informal one? Which is almost certainly not true?

Ya'll must be super fun at parties.

Re: The xz sshd backdoor rabbithole goes quite a bit deeper

#264

Post by timschmidt » Sun, Apr 07, 2024, 9:01 PM UTC

_8j50 wrote: post #254

afiori wrote: post #231

Earlier quoted context omitted.

For bytedance/TikTok the question is not really "should the US ban this company" but rather "should the government be able to ban any companies it wants (and also make it illegal for VPNs to allow US users to access relevant services/websites) without having to provide any substantial evidence? Which is a very different question in practice

US companies? I'm with you, no! Foreign companies, absolutley. Even the suspicion of malicious abuse should be enough to ban a foreign company. Foreign persons and entities have no rights in the US and our government owes them as much explanation as they give us when they ban US companies on a whim.

> Foreign persons and entities have no rights in the US

"Yes, immigrants are protected by the U.S. Constitution.

The brief answer is “Yes.” When it comes to key constitutional provisions like due process and equal treatment under the law, the U.S. Constitution applies to all persons – which includes both documented and undocumented immigrants – and not just U.S. citizens. Outside the context of immigration policy, the Constitution limits government power over individuals but this does not mean that constitutional rights are absolute."

https://pennstatelaw.psu.edu/sites/default/files/Are%20Immig...

Re: The xz sshd backdoor rabbithole goes quite a bit deeper

#265

Post by rstuart4133 » Sun, Apr 07, 2024, 9:15 PM UTC

jwilk wrote: post #154

heyoni wrote: post #52

Earlier quoted context omitted.

I thought performance was actually fine? It only dragged when using valgrind, hence the rhetoric that it took some really unlikely circumstances for it to be detected that quickly.

No, it wasn't fine. From the advisory ( https://news.ycombinator.com/item?id=39865810 ): > With the backdoored liblzma installed, logins via ssh become a lot slower.

It was noticed because of it's CPU usage. It seems most people think "that was lucky". It wasn't lucky, it was inevitable.

It happened to be noticed by someone doing benchmarking, but there is another category of machines out there it would hit hard: low end VM's running an ssh server. I've had my low end VM's hit by exactly the same thing the postgres benchmarker saw, but on these box's it isn't just annoying. There are so many ssh logins happening the OOM killer comes out to play but these ssh logins are tiny so it tends to kill the real stuff you've got the box doing, like web serving.

A 2 or 3 fold increase in CPU would suddenly bring a lot of VM to their knees. At least thousands of them. It would be noticed.

Re: The xz sshd backdoor rabbithole goes quite a bit deeper

#266

Post by usr1106 » Sun, Apr 07, 2024, 9:40 PM UTC

timschmidt wrote: post #257

usr1106 wrote: post #189

Earlier quoted context omitted.

The link provides interesting reading, but I believe Moxie must have changed his opinion later: I have never had Google Play Store on my phone, but I could install Signal. I am pretty sure I did not install it from any dodgy site. It warned when it got outdated. Not sure how updates work, not using it anymore.

No, he hasn't changed his mind (93 closed issues over 8 years related to F-droid, many asking for F-Droid distribution: https://github.com/signalapp/Signal-Android/issues?q=is%3Ais... ). Signal distributes their own APK from their own site, but still does now allow F-Droid to distribute a version, or for any version built or distributed by anyone other than Signal to connect to the Signal servers. Imagine Jia Tan's b…

His standpoint is unchanged regarding F-Droid, but not regarding distributing APKs themselves. In the linked issue he still argues that having users to enable "allow 3rd party APKs" is such a bad idea, that they will not provide any APKs directly.

Re: The xz sshd backdoor rabbithole goes quite a bit deeper

#267

Post by timschmidt » Sun, Apr 07, 2024, 9:59 PM UTC

usr1106 wrote: post #266

timschmidt wrote: post #257

Earlier quoted context omitted.

No, he hasn't changed his mind (93 closed issues over 8 years related to F-droid, many asking for F-Droid distribution: https://github.com/signalapp/Signal-Android/issues?q=is%3Ais... ). Signal distributes their own APK from their own site, but still does now allow F-Droid to distribute a version, or for any version built or distributed by anyone other than Signal to connect to the Signal servers. Imagine Jia Tan's b…

His standpoint is unchanged regarding F-Droid, but not regarding distributing APKs themselves. In the linked issue he still argues that having users to enable "allow 3rd party APKs" is such a bad idea, that they will not provide any APKs directly.

Here's the APK provided by Signal: https://signal.org/android/apk/

Cute how it's labeled "Danger Zone". So official Signal provided install methods include Google Play Store, or enabling third party APKs and downloading directly from Signal. How the second differs from an official Signal provided and signed F-Droid repository in Moxie's mind is anyone's guess.

What Signal _does not_ allow are APKs built by third parties being distributed under the Signal name, or connecting to Signal servers. Which calls into question the build process itself - the very thing exploited in the XZ backdoor. One either trusts Signal to build the software without backdoors, or doesn't use Signal at all. There is no allowed in between.

Re: The xz sshd backdoor rabbithole goes quite a bit deeper

#268

Post by fragmede » Sun, Apr 07, 2024, 10:03 PM UTC

timschmidt wrote: post #267

usr1106 wrote: post #266

Earlier quoted context omitted.

His standpoint is unchanged regarding F-Droid, but not regarding distributing APKs themselves. In the linked issue he still argues that having users to enable "allow 3rd party APKs" is such a bad idea, that they will not provide any APKs directly.

Here's the APK provided by Signal: https://signal.org/android/apk/ Cute how it's labeled "Danger Zone". So official Signal provided install methods include Google Play Store, or enabling third party APKs and downloading directly from Signal. How the second differs from an official Signal provided and signed F-Droid repository in Moxie's mind is anyone's guess. What Signal _does not_ allow are APKs built by third part…

Which is to say, they don't trust 3rd parties to build the software without backdoors. Can't say I blame them. Allowing for 3rd party clients opens Signal to backdoored clients. I know you think that people would only make 3rd-party clients for good, and not do bad things with that power, and no one would be foolish enough to download Definitely-not-backdoored-Signal-client from hackers.ru, but I'm pretty sure that's exactly what would happen. An APT could exploit a Pegasus-like zero-day in iOS and install a replacement, backdoored client on a victim's device. Not allowing 3rd party clients doesn't totally protect against that, but it goes a long way.

Re: The xz sshd backdoor rabbithole goes quite a bit deeper

#269

Post by timschmidt » Sun, Apr 07, 2024, 10:15 PM UTC

fragmede wrote: post #268

timschmidt wrote: post #267

Earlier quoted context omitted.

Here's the APK provided by Signal: https://signal.org/android/apk/ Cute how it's labeled "Danger Zone". So official Signal provided install methods include Google Play Store, or enabling third party APKs and downloading directly from Signal. How the second differs from an official Signal provided and signed F-Droid repository in Moxie's mind is anyone's guess. What Signal _does not_ allow are APKs built by third part…

Which is to say, they don't trust 3rd parties to build the software without backdoors. Can't say I blame them. Allowing for 3rd party clients opens Signal to backdoored clients. I know you think that people would only make 3rd-party clients for good, and not do bad things with that power, and no one would be foolish enough to download Definitely-not-backdoored-Signal-client from hackers.ru, but I'm pretty sure that's…

> An APT could exploit a Pegasus-like zero-day in iOS and install a replacement

Nothing about the way Signal currently does things prevents this from happening today.

Disallowing third party builds only serves to reduce eyes on the build tooling, which we've learned is a great place to hide backdoors.

Equating F-Droid with hackers.ru is a distasteful strawman. F-Droid appear to run as transparent and credible a distribution as Debian or Fedora. Credible enough that the Tor project distributes it's privacy-focused software via F-Droid.

Re: The xz sshd backdoor rabbithole goes quite a bit deeper

#270

Post by cjbprime » Sun, Apr 07, 2024, 11:20 PM UTC

Jasper_ wrote: post #132

orbital-decay wrote: post #119

Earlier quoted context omitted.

You probably have too high expectations when you hear the "state-sponsored" part. Every large organization will inevitably end up like any other. They also have bureaucracy, deadlines, production cycle, poor communication between teams, the recent iOS "maybe-a-backdoor" story also shows that they don't always care about burning the vulnerabilities because they amassed a huge pile of them.

Eh. Take a look at other state-sponsored attackers. We know they have 0-days for iOS, we know they've been used, but even Apple doesn't know what they are since they are so good at hiding their tracks. I don't think a state-sponsored attack would upload their payload to the git repo and tarball for all to stare at after it's been found out, which only took about a month. NSO Group built a turing-complete VM out of a…

You are severely underestimating this attacker and their sponsors. Amateur hacker rings do not spend two years actually diligently maintaining the software they will later backdoor. It would not make any sense in the world of ransomware attacks and bitcoin payouts.

> Uploading a payload to the world wide web and calling it bad-3-corrupt_lzma2.xz is clownshoes by comparison.

It has to be on the world wide web for distros to package and ship it. And this was actually the best disguise possible: this directory is one where it is normal and expected to have binary files that are not obviously analyzable, as this one wasn't -- another part of the malware rearranged it to become non-corrupt at exploitation-time.

See this note from the README for the test directory:

> This directory contains bunch of files to test handling of .xz, .lzma (LZMA_Alone), and .lz (lzip) files in decoder implementations. Many of the files have been created by hand with a hex editor, thus there is no better "source code" than the files themselves.

It is a brilliant solution to the problem of "okay, but where do I hide the malware payload, given the constraint that it has to be distributed alongside the code and tarballs?". The attack was detected, but not because of this file, and it's unlikely to me that it ever would have been detected purely by the means of this file, given the comment above.