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

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.




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

Search: