Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I haven't seen Thomas Roccia's infographic mentioned here yet: https://twitter.com/fr0gger_/status/1774342248437813525


That seems to be largely grasped at straws and connecting dots without reason.

For example oss-fuzz was building xz by cloning the github repo directly. There was never a chance for oss-fuzz to discover the backdoor, because only the tarball had it, not the repo itself. So that oss-fuzz PR might genuinely just be a genuine thing unrelated to the backdoor.


The ifunc part looked more legitimate, it was used to switch between optimized implementations of CRC. So that part was in the git repo. https://github.com/google/oss-fuzz/pull/10667


Jia Tan asked distros to update quickly just before it became public. How possible is it, there is another account / person who learned earlyer from people around Andreas Freund, the backdoor would become public. How possible is it, there is still another insider around?


That's probably because of this (as mentioned in the timeline):

>2024-02-29: On GitHub, @teknoraver https://github.com/systemd/systemd/pull/31550 to stop linking liblzma into libsystemd. It appears that this would have defeated the attack. https://doublepulsar.com/inside-the-failed-attempt-to-backdo... that knowing this was on the way may have accelerated the attacker’s schedule. It is unclear whether any earlier discussions exist that would have tipped them off.


rwmj did mention about an unintentional embargo break, so I wonder whether this is GitHub issue is actually it.


Hi,

I'm the author of such PR. My purpose was to trim down the size of the initram files by removing unneeded dependencies.

I couldn't imagine that liblzma had a backdoor.


Hi! Was there any discussion on any mailing lists ahead of time, or was your PR the first public mention of that idea? Thanks.


Yes, there was an effort to turn all the dependencies into on demand loads, where possible. It started in 2020 with libpcre2: https://github.com/systemd/systemd/pull/16260

But many others followed, like libselinux: https://github.com/systemd/systemd/pull/19997

libqrencode: https://github.com/systemd/systemd/pull/16145

p11kit: https://github.com/systemd/systemd/pull/25771

tpm2-util: https://github.com/systemd/systemd/pull/28333

libiptc: https://github.com/systemd/systemd/pull/29836

libkmod: https://github.com/systemd/systemd/pull/31131

Exactly during the development of the libkmod PR, someone noted that libxz could be lazily loaded too: https://github.com/systemd/systemd/pull/31131#issuecomment-1...

And so I proposed myself to to the job, nothing less, nothing more.

If you look at the code of the other PRs, you see that they are very very similar, there are also macros to easy this task, like DLSYM_FUNCTION()


Hi @rsc, I just saw your update on the timeline.

To be more precise, the first public comment asking to dlopenify lzma was dated 30 Jan by Daan: https://github.com/systemd/systemd/pull/31131#issuecomment-1...

The day after, it was reiterated by Lennart: https://github.com/systemd/systemd/pull/31131#issuecomment-1...

But if you look in the systemd repo there is a TODO file with a section of libraries which needs to be lazy loaded. liblzma was added in this list in June 2020 (https://github.com/systemd/systemd/commit/cdfd853744ee934869...) by Lennart, and removed by me just after that my PR was merged.


Updated. Thanks!


There were also changes to systemd happening around that time which would have prevented the backdoor from working. See the timeline article by the same author linked in this one.


Right. Way too much coincidence. Jia Tan found out that it was about to become public and threw a Hail Mary. How did he find out?


I think the RedHat Valgrind report on 2024-03-04 made the Jia Tan team panic, since the one public rwmj stack trace pointed the finger directly at the backdoor. All it would take is someone looking closely at that failure to expose the whole operation. They fixed it on 2024-03-09, but then two weeks later distros still had not updated to the new version, and every day is another day that someone might hit the Valgrind failure and dig. I think that's why the sockpuppets came back on 2024-03-25 begging Debian to update. And then on the Debian thread there was pushback because they weren't the maintainer (except probably they were), so once Debian was updated, Jia Tan had to be the account that asked Ubuntu to update.


That seems like a breach that they went forward with the update based on some random persons request. Oh you're getting pushy? I guess we better listen to this guy.


The update was pulling from trusted upstream archives. I'm sure Debian verified that.


If the stakes weren't so high, this would be a damn fun game of murder mystery.


This just gives a partial high-level look at how the exploit gets planted in liblzma, it doesn't cover how the exploit works or its contents at all.


Thx. Timeline shows attack begun by adding ignore entry in .gitignore file. That is hard to detect nowadays.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: