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

What we know about the xz Utils backdoor that almost infected the world

arstechnica.com

Post reply on HN
Print view View original

71–80 of 336 posts

Re: What we know about the xz Utils backdoor that almost infected the world

#71

Post by bogwog »

hk__2 wrote: post #38
mapasj wrote: post #11

I’m guessing the original maintainer of xz handed responsibilities to Jia Tan without ever seeing him/her or at least sharing a phone call. Is that common to only communicate only through email/github? I guess some maintainers of open source projects will be more cautious after this story.

> Is that common to only communicate only through email/github? Yes. I’ve joined half a dozen open-source projects of various sizes (from 100 to 30k stars on GitHub) without ever calling anyone; written communication is the standard.

Sure, but handing over maintainership is a different situation from accepting a few PRs

Re: What we know about the xz Utils backdoor that almost infected the world

#72

Post by chpatrick »

mrkramer wrote: post #64
4bpp wrote: post #58

Earlier quoted context omitted.

The interest in OSS-Fuzz was because it was used to monitor libxz, and so one of the necessary subgoals was to trick its maintainers into exempting libxz from a check that may have caught the backdoor, or at least drawn attention to it for unrelated reasons: https://github.com/google/oss-fuzz/pull/10667

So did he plan all this from the beginning or somewhere down the line he went full yolo?! I am looking at his mailing chat[0] and he seemed pretty enthusiastic about improving and fixing XZ. [0] https://www.mail-archive.com/search?l=xz-devel@tukaani.org&q...

I mean if I was working for a state and had the job of compromising xz that's exactly what I would do.

Re: What we know about the xz Utils backdoor that almost infected the world

#73

Post by sokoloff »

jorams wrote: post #54
hk__2 wrote: post #33

Earlier quoted context omitted.

> Or… just have downstream users run autotools as part of the build? See point 3: > 3. A corollary of (1) and (2) is that autotools is bad and the autotools culture is bad.

Whether it's autotools or not is not very relevant to point 1a. I'm also confused why point 1 leads to 1a, and not to the opposite of 1a. Source distribution tarballs should not contain code different from what's in the source repository. They should not contain automatically generated artifacts, since those should not be in the repository, since they are by definition not the source , but output of some kind of buil…

That very last point seems like something that's fairly amenable to automation, though. (Then, that automation can be attacked, but that seems like one more [fairly independent] layer that must be bypassed to execute one of these attacks.)

Re: What we know about the xz Utils backdoor that almost infected the world

#74

Post by okr »

turol wrote: post #57
josephg wrote: post #53

Earlier quoted context omitted.

I don’t understand how this is still the best way to test if features are available in C. Can’t the OS / environment provide a “features_available” JSON blob listing all the features on the host system? Is AVX2 available on the cpu? OpenSSL? (And if so, where?) and what about kernel features like io_uring? Doing haphazard feature detection by test compiling random hand written C programs in a giant sometimes autogene…

https://xkcd.com/927/

"How to demotivate people and prevent innovation!"

Re: What we know about the xz Utils backdoor that almost infected the world

#75

Post by supposemaybe »

kuschku wrote: post #66
supposemaybe wrote: post #50

Earlier quoted context omitted.

I said this days ago, but re timezones - they are meaningless as even GCHQ and NSA etc will place false flags in code which has any kind of risk of exposure. I first learned about those techniques from all the high profile intelligence agency leaks from the USA who were performing those themselves.

It's not that simple. You can falsify a lot of things, but you can't easily falsify the working hours at which you reply to issues or push commits without taking a lot of care. Especially when DST has to be considered. Sure, the +0800 timestamps are definitely fake. A handful of timestamps that were later scrubbed show +0200 and +0300, though. And all the commits match 9am to 6pm working hours if you interpret them a…

Re the falsifying working hours, wouldn’t these boffins be able to automate Git commits at certain times or even pass instructions to another team who is working the late night shift to post these changes etc.

I went to MacDonald’s last night, it is open 24/7, these spy agencies surely aren’t more lazy than minimum wage MacD employees - I am sure they work around the clock. Plus, you have night hawks like me who get more stuck in to a project at 4am and sleep through the day.

Israeli intelligence, ah probably. Wouldn’t be surprised. I imagine if it was GCHQ, it wouldn’t have been so noisy and got uncovered like this.

Re: What we know about the xz Utils backdoor that almost infected the world

#76

Post by jbergknoff »

heresie-dabord wrote: post #45
EdiX wrote: post #19

My personal takeaways from this: 1. Source distribution tarballs that contain code different from what's in the source repository are bad, we should move away from them. The other big supply chan attack (event-stream) also took advantage of something similar. 1a. As a consequence of (1) autogenerated artifacts should always be committed. 2. Autogenerated artifacts that everyone pagedowns over during code reviews is a…

More personal observations: 8. Consumers are naive, yes. But the software industry itself is naive about the security threat. 9. The social exploit is part of the code exploit. 10. The FOSS axiom "More Eyes On The Code" works, but only if the "eyes" are educated. FOSS needs material support from industry. A MSFT engineer caught this exploit, but it still was released to G.A. in Fedora 41, openSUSE, and Kali . 11. The…

> 10. The FOSS axiom "More Eyes On The Code" works, but only if the "eyes" are educated.

One thing that could help with this is if somebody points an LLM at all these foundational repositories, prompted with "does this code change introduce any security issues?".

Re: What we know about the xz Utils backdoor that almost infected the world

#77

Post by thesuperbigfrog »

josephg wrote: post #53
disconnect3d wrote: post #23

Earlier quoted context omitted.

I would personally add: test your build scripts. There are so many bugs like the "added dot to disable landlock" added as part of this action (which can also be typos [0]), not to mention that relying on some tools in autoconf to set feature flags will just disable them if those tools are not present [1]. [0] https://twitter.com/disconnect3d_pl/status/17744965092596453... [1] https://twitter.com/disconnect3d_pl/statu…

I don’t understand how this is still the best way to test if features are available in C. Can’t the OS / environment provide a “features_available” JSON blob listing all the features on the host system? Is AVX2 available on the cpu? OpenSSL? (And if so, where?) and what about kernel features like io_uring? Doing haphazard feature detection by test compiling random hand written C programs in a giant sometimes autogene…

>> Can’t the OS / environment provide a “features_available” JSON blob listing all the features on the host system? Is AVX2 available on the cpu? OpenSSL? (And if so, where?) and what about kernel features like io_uring?

There are some utilities like pkg-config [1] and /proc/cpuinfo [2] that try to provide useful configuration information in distribution agnostic ways.

[1] https://en.wikipedia.org/wiki/Pkg-config

[2] https://www.baeldung.com/linux/proc-cpuinfo-flags

>> Doing haphazard feature detection by test compiling random hand written C programs in a giant sometimes autogenerated configure script is an icon of everything wrong with Unix.

True, but it works quite well which is why it is widely used. If you need to ensure that your C code will implement a desired feature, testing it with a small program before building makes a lot of sense. With different operating systems running various C compilers that all work slightly differently, it is a proven approach that achieves the needed outcome, however ugly it might be.

Re: What we know about the xz Utils backdoor that almost infected the world

#78

Post by kuschku »

supposemaybe wrote: post #75
kuschku wrote: post #66

Earlier quoted context omitted.

It's not that simple. You can falsify a lot of things, but you can't easily falsify the working hours at which you reply to issues or push commits without taking a lot of care. Especially when DST has to be considered. Sure, the +0800 timestamps are definitely fake. A handful of timestamps that were later scrubbed show +0200 and +0300, though. And all the commits match 9am to 6pm working hours if you interpret them a…

Re the falsifying working hours, wouldn’t these boffins be able to automate Git commits at certain times or even pass instructions to another team who is working the late night shift to post these changes etc. I went to MacDonald’s last night, it is open 24/7, these spy agencies surely aren’t more lazy than minimum wage MacD employees - I am sure they work around the clock. Plus, you have night hawks like me who get…

> Re the falsifying working hours, wouldn’t these boffins be able to automate Git commits at certain times or even pass instructions to another team who is working the late night shift to post these changes etc.

Is it possible? Definitely. But that's extremely rare, especially if you want to keep a relatively natural pattern for the commits and replies.

You'd basically have to have a team of devs working at really odd times and a queuing system that automatically queues all emails, github interactions, commits, etc to dispatch them at correctly distributed timestamps.

And you'd need a source pattern to base your distribution on, which is hard to correctly model as well.

e.g., if someone slept badly one night, the next morning their interactions shift slightly back and are more sparse in the morning. Their lunch break will also shift due to that. Such changes usually are most prominent in the days surrounding DST changes.

Re: What we know about the xz Utils backdoor that almost infected the world

#79

Post by Osiris »

jbergknoff wrote: post #76
heresie-dabord wrote: post #45

Earlier quoted context omitted.

More personal observations: 8. Consumers are naive, yes. But the software industry itself is naive about the security threat. 9. The social exploit is part of the code exploit. 10. The FOSS axiom "More Eyes On The Code" works, but only if the "eyes" are educated. FOSS needs material support from industry. A MSFT engineer caught this exploit, but it still was released to G.A. in Fedora 41, openSUSE, and Kali . 11. The…

> 10. The FOSS axiom "More Eyes On The Code" works, but only if the "eyes" are educated. One thing that could help with this is if somebody points an LLM at all these foundational repositories, prompted with "does this code change introduce any security issues?".

Not sure why an LLM would be better than existing static analysis tools. Many projects I have worked on run static vulnerability analysis on PRs.

Re: What we know about the xz Utils backdoor that almost infected the world

#80

Post by Kuinox »

gumby wrote: post #67
EdiX wrote: post #19

My personal takeaways from this: 1. Source distribution tarballs that contain code different from what's in the source repository are bad, we should move away from them. The other big supply chan attack (event-stream) also took advantage of something similar. 1a. As a consequence of (1) autogenerated artifacts should always be committed. 2. Autogenerated artifacts that everyone pagedowns over during code reviews is a…

> 1a. As a consequence of (1) autogenerated artifacts should always be committed. I philosophically and fundamentally hate this suggestion, but have to agree with it. It's going to make porting harder, but is sadly a cost worth paying. > dependencies are maintenance burden and a security risk, this needs to be weighted against the functionality they bring in Tough call. A major library is more likely to be bug fixed…

Why would it make porting harder ?
Post reply on HN