Live data from Hacker News

Backdoor in upstream xz/liblzma leading to SSH server compromise

openwall.com

671–680 of 1001 posts

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

#671
Notes on time stamps and time zones.

A few interesting bits that I haven't fully fleshed out. TLDR: Some people have been throwing around that Jia is from “China,” but it seems also quite possible that Jia is from somewhere in Eastern Europe pretending to be from China. In addition, Lasse Collin and Hans Jansen are from the same EET time zone.

The following analysis was conducted on JiaT75’s (https://github.com/JiaT75?tab=overview&from=2021-12-01&to=20...) commits to the XZ repository, and their time stamps.

Observation 1: Time zone basic analysis

Here is the data on Jia’s time zone and the number of times he was recorded in that time zone: 3: + 0200 (in winter: February and November) 6: +0300 (in summer: in Jun, Jul, early October) 440: +0800

1. The +800 is likely CST. China (or Indonesia or Philippines), given that Australia does daylight savings time and almost no one lives in Siberia and the Gobi dessert. 2. The +0200/+0300, if we are assuming that this is one location, is likely on EET (Finland, Estonia, Latvia, Lithuania, Ukraine, Moldavia, Romania, Bulgaria, Greece, Turkey). This is because we see a switch from +300 in the winter (past the last weekend of October) and +200 in the summer (past the last Sunday in March). 1. Incidentally, this seems to be the same time zone as Lasse Collin and Hans Jansen…

Observation 2: Time zone inconsistencies

Let’s analyze the few times where Jia was recorded in a non +800 time zone. Here, we notice that there are some situations where Jia switches between +800 and +300/+200 in a seemingly implausible time. Indicating that perhaps he is not actually in +800 CST time, as his profile would like us to believe.

Jia Tan Tue, 27 Jun 2023 23:38:32 +0800 —> 23:38 + 8 = 7:30 (+ 1) Jia Tan Tue, 27 Jun 2023 17:27:09 +0300 —> 17:27 + 3 = 20:30 —> about a 9 hour difference, but a flight from China to anywhere in Eastern Europe is at a min 10 hours

Jia Tan Thu, 5 May 2022 20:53:42 +0800 Jia Tan Sat, 19 Nov 2022 23:18:04 +0800 Jia Tan Mon, 7 Nov 2022 16:24:14 +0200 Jia Tan Sun, 23 Oct 2022 21:01:08 +0800 Jia Tan Thu, 6 Oct 2022 21:53:09 +0300 —> 21:53 + 3 = 1:00 (+1) Jia Tan Thu, 6 Oct 2022 17:00:38 +0800 —> 17:00 + 8 = 1:00 (+1) Jia Tan Wed, 5 Oct 2022 23:54:12 +0800 Jia Tan Wed, 5 Oct 2022 20:57:16 +0800 —> again, given the flight time, this is even more impossible

Jia Tan Fri, 2 Sep 2022 20:18:55 +0800 Jia Tan Thu, 8 Sep 2022 15:07:00 +0300 Jia Tan Mon, 25 Jul 2022 18:30:05 +0300 Jia Tan Mon, 25 Jul 2022 18:20:01 +0300 Jia Tan Fri, 1 Jul 2022 21:19:26 +0800 Jia Tan Thu, 16 Jun 2022 17:32:19 +0300 Jia Tan Mon, 13 Jun 2022 20:27:03 +0800 —> the ordering of these time stamps and the switching back and forth between time zones looks strange.

Jia Tan Thu, 15 Feb 2024 22:26:43 +0800 Jia Tan Thu, 15 Feb 2024 01:53:40 +0800 Jia Tan Mon, 12 Feb 2024 17:09:10 +0200 Jia Tan Mon, 12 Feb 2024 17:09:10 +0200 Jia Tan Tue, 13 Feb 2024 22:38:58 +0800 —> this travel time is possible, but the duration of stay is unlikely

Observation 3: Strange record of time stamps

It seems that from the commits, often the time stamps are out of order. I am not sure what would cause this other than some tampering.

Observation 4: Bank holiday inconsistencies

We notice that Jia’s work schedule and holidays seems to align much better with an Eastern European than a Chinese person.

Disclaimer: I am not an expert in Chinese holidays, so this very well could be inaccurate. I am referencing this list of bank holidays:(https://www.bankofchina.co.id/en-id/service/information/late...)

Chinese bank holidays (just looking at 2023): - Working on 2023, 29 September: Mid Autumn Festival - Working on 2023, 05 April: Tomb Sweeping Day - Working on 2023, 26, 22, 23, 24, 26, 27 Jan: Lunar New Year

Eastern European holidays: - Never working on Dec 25: Christmas (for many EET countries) - Never working Dec 31 or Jan 1: New Years

Observation 5: Little weekend work —> salary job?

The most common working days for Jia were Tue (86), Wed (85), Thu (89), and Fri (79). If we adjust his time zone to EET, then that means he is usually working 9 am to 6 pm. This makes much more sense than someone working at midnight and 1 am on a Tuesday night.

These times also line up well with Hans Jansen and Lasse Collin.

I think it is more likely that Jia does this as part of his work… somewhere in Eastern Europe. Likely working with, or in fact being one and the same as, Hans Jansen and Lasse Collin.

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

#672
TLDR: Some people have been throwing around “China,” but it seems also quite possible that Jia is from somewhere in Eastern Europe pretending to be from China. In addition, Lasse Collin and Hans Jansen are from the same EET time zone.

These are my notes on time stamps/zones. There are a few interesting bits that I haven't fully fleshed out.

The following analysis was conducted on JiaT75’s (https://github.com/JiaT75?tab=overview&from=2021-12-01&to=20...) commits to the XZ repository, and their time stamps.

Observation 1: Time zone basic analysis

Here is the data on Jia’s time zone and the number of times he was recorded in that time zone:

3: + 0200 (in winter: February and November)

6: +0300 (in summer: in Jun, Jul, early October)

440: +0800

1. The +800 is likely CST. China (or Indonesia or Philippines), given that Australia does daylight savings time and almost no one lives in Siberia and the Gobi dessert.

2. The +0200/+0300, if we are assuming that this is one location, is likely on EET (Finland, Estonia, Latvia, Lithuania, Ukraine, Moldavia, Romania, Bulgaria, Greece, Turkey). This is because we see a switch from +300 in the winter (past the last weekend of October) and +200 in the summer (past the last Sunday in March).

Incidentally, this seems to be the same time zone as Lasse Collin and Hans Jansen…

Observation 2: Time zone inconsistencies

Let’s analyze the few times where Jia was recorded in a non +800 time zone. Here, we notice that there are some situations where Jia switches between +800 and +300/+200 in a seemingly implausible time. Indicating that perhaps he is not actually in +800 CST time, as his profile would like us to believe.

Jia Tan Tue, 27 Jun 2023 23:38:32 +0800 —> 23:38 + 8 = 7:30 (+ 1) Jia Tan Tue, 27 Jun 2023 17:27:09 +0300 —> 17:27 + 3 = 20:30 —> about a 9 hour difference, but flight from China to anywhere in Eastern Europe is at a min 10 hours

Jia Tan Thu, 5 May 2022 20:53:42 +0800

Jia Tan Sat, 19 Nov 2022 23:18:04 +0800

Jia Tan Mon, 7 Nov 2022 16:24:14 +0200

Jia Tan Sun, 23 Oct 2022 21:01:08 +0800

Jia Tan Thu, 6 Oct 2022 21:53:09 +0300 —> 21:53 + 3 = 1:00 (+1)

Jia Tan Thu, 6 Oct 2022 17:00:38 +0800 —> 17:00 + 8 = 1:00 (+1)

Jia Tan Wed, 5 Oct 2022 23:54:12 +0800

Jia Tan Wed, 5 Oct 2022 20:57:16 +0800

—> again, given the flight time, this is even more impossible

Jia Tan Fri, 2 Sep 2022 20:18:55 +0800

Jia Tan Thu, 8 Sep 2022 15:07:00 +0300

Jia Tan Mon, 25 Jul 2022 18:30:05 +0300

Jia Tan Mon, 25 Jul 2022 18:20:01 +0300

Jia Tan Fri, 1 Jul 2022 21:19:26 +0800

Jia Tan Thu, 16 Jun 2022 17:32:19 +0300

Jia Tan Mon, 13 Jun 2022 20:27:03 +0800

—> the ordering of these time stamps, and the switching back and forth looks strange.

Jia Tan Thu, 15 Feb 2024 22:26:43 +0800

Jia Tan Thu, 15 Feb 2024 01:53:40 +0800

Jia Tan Mon, 12 Feb 2024 17:09:10 +0200

Jia Tan Mon, 12 Feb 2024 17:09:10 +0200

Jia Tan Tue, 13 Feb 2024 22:38:58 +0800

—> this travel time is possible, but the duration of stay is unlikely

Observation 3: Strange record of time stamps It seems that from the commits, often the time stamps are out of order. I am not sure what would cause this other than some tampering.

Observation 4: Bank holiday inconsistencies

We notice that Jia’s work schedule and holidays seem to align much better with an Eastern European than a Chinese person.

Disclaimer: I am not an expert in Chinese holidays, so this very well could be inaccurate. I am referencing this list of bak holidays:(https://www.bankofchina.co.id/en-id/service/information/late...)

Chinese bank holidays (just looking at 2023):

- Working on 2023, 29 September: Mid Autumn Festival

- Working on 2023, 05 April: Tomb Sweeping Day

- Working on 2023, 26, 22, 23, 24, 26, 27 Jan: Lunar New Year

Eastern European holidays:

- Never working on Dec 25: Christmas (for many EET countries)

- Never working Dec 31 or Jan 1: New Years

Observation 5: No weekend work —> salary job?

The most common working days for Jia was Tue (86), Wed (85), Thu (89), and Fri (79). If we adjust his time zone to be EET, then that means he is usually working 9 am to 6 pm. This makes much more sense than someone working at midnight and 1 am on a Tuesday night.

These times also line up well with Hans Jansen and Lasse Collin.

I think it is more likely that Jia does this as part of his work… somewhere in Eastern Europe. Likely working with, or in fact being one and the same as, Hans Jansen and Lasse Collin.

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

#675
Well isn't this an interesting commit. He finished his inject macro to compose the payload at build, so now he can start clearing up the repo so none of that shit gets seen when cruising through it.

https://git.tukaani.org/?p=xz.git;a=commitdiff;h=4323bc3e0c1...

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

#676
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…

> If you're not on a rolling release distro, your version is probably older. Ironic considering security is often advertised as a feature of rolling release distros. I suppose in most instances it does provide better security, but there are some advantages to Debian's approach (stable Debian, that is).

i mean, rolling implies rolling 0-days, too.

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

#678

Earlier quoted context omitted.

Probably a state actor. You can look far into the future when you’re working for the party.

Which like, also wouldn't be totally weird if I found out that the xz or whatever library maintainer worked for the DoE as a researcher? I kind of expect governments to be funding this stuff.

From what I read on masto, the original maint had personal life breakdown, etc. Their interest in staying as primary maint is gone.

This is a very strong argument for FOSS to pick up the good habit of ditching/un-mainlining projects where they are sitting around for state actors to volunteer injecting commits to, and dep-stripping active projects from this cruft.

Who wants to maintain on a shitty compression format? Someone who is dephunting, it turns out.

Okay so your pirate-torrent person needs liblzma.so Offer it in the scary/oldware section of the package library that you need to hunt down the instructions to turn on. Let the users see that it's marked as obsolete, enterprises will see that it should go on the banlist.

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

#679
post #665
post #477

Earlier quoted context omitted.

And, Joey Hess has counted at least 750 commits to xz from that handle. https://hachyderm.io/@joeyh/112180715824680521 This does not look trust-inspiring. If the code is complex, there could be many more exploits hiding.

If this is a conspiracy or a state-sponsored attack, they might have gone specifically for embedded devices and the linux kernel. Here archived from tukaani.org: https://web.archive.org/web/20110831134700/http://tukaani.or... > XZ Embedded is a relatively small decompressor for the XZ format. It was developed with the Linux kernel in mind, but is easily usable in other projects too. > *Features* > * Compiled code 8-2…

[flagged]

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

#680

A lot of eyes will be dissecting this specific exploit, and investigating this specific account, but how can we find the same kind of attack in a general way if it’s being used in other projects and using other contributor names?

Build-related fixes are only treating the symptoms, not the disease. The real fix would be better sandboxing and capability-based security[1] built into major OSes which make backdoors a lot less useful. Why does a compression library have the ability to "install an audit hook into the dynamic linker" or anything else that isn't compressing data? No amount of SBOMs, reproducible builds, code signing, or banning binar…

That's why I always raise concerns about JEP 411 - removal of SecurityManager from Java without any replacement.
Post reply on HN