Project statement about xz 5.6.1 (CVE-2024-3094)

Hi,

tl;dr OpenWrt seems to be not affected by the CVE-2024-3094

As you may be aware, malicious code was identified in the xz upstream tarballs starting from version 5.6.0. The development snapshots of OpenWrt were utilizing this compromised library version.

Fortunately, the snapshots builds relied on source code tarballs from GitHub releases, which are generated automatically. These contained only the dormant segment of the malicious code. The crucial component that would activate the backdoor during the build process was not detected in the scrutinized tarball archives.

For those interested, the source tarballs employed in the official OpenWrt snapshot builds are still accessible:

Binary packages built using affected xz sources can be downloaded from https://mirror-03.infra.openwrt.org/snapshots/packages/xz-5.6.1-ipks.tar.gz (sha256sum: a376b30cc8afe2ebf92316b47c640e845cd76bef4f2c593ca22e6fc12deb580d).

Timeline

  • 2024-03-29T15:17:00Z Started investigating the issue
  • 2024-03-29T15:59:00Z Reverting the xz 5.6.1 package version bumps
  • 2024-03-29T16:11:00Z Moved affected sources/packages to .backdoored file suffixes on downloads.openwrt.org and sources.openwrt.org servers
  • 2024-03-29T18:08:00Z CDN cache invalidated as well

Happy Easter! :slight_smile:

44 Likes

<soapbox_mode=on>
I'll add that this incident reinforces my belief that an edge device should have minimum complexity and attack surface. In other words, don't get a big x86 box, run some VM host on it and make your gateway an OpenWrt VM/container on that device. Keep that perimeter simple and clean, folks, the less stuff you potentially expose the better...

10 Likes

For those who are curious, here's the best write-up I've read thus far.

6 Likes

Out of pure curiosity, does xz-utils have sponsors, is this another case of an open source project solely relying on contributors working in their free time?

This vulnerability does not work if system does note have systemd. So this is not a issue for systems which does not have systemd.

1 Like

Yes it is - see this discussion
https://www.mail-archive.com/xz-devel@tukaani.org/msg00567.html

3 Likes

Exactly, and here's another take: https://lwn.net/Articles/967420/

3 Likes

A state actor using social engineering to become a committer/maintainer of something useful enough to backdoor. Who would have thought?

That there are a lot of eyes on FOSS provides some assurance. Someone's eyes did catch this xz backdoor after all. But I'll throw this example out there for thought: OpenWrt Commit a112ed4126.....

We all know who Felix is, and he's certainly earned great trust. But from a process standpoint, if the same person can be the author, committer and sign off on a change....how many eyes are there?

4 Likes

Most of the people working on OpenWRT are fairly well known like Felix but I get your point.

But if we want to implement the four-eyes principle we need extra manpower while we are already lacking in that department.

Difficult situation :frowning:

5 Likes

Here's an interesting read that sheds a lot of light on the social engineering aspect of the attack. https://research.swtch.com/xz-timeline

Just as with phishing attacks, shaming and a sense of urgency are used to drive the attack forward.

5 Likes

makes me wonder if this is just a one time thing or are we looking at the top of the iceberg where back doors are already implemented without notion or people are trying to "hi-jack" other projects as well.

2 Likes

As mentioned by the man who discovered the backdoor: "There was a lot of coincidence..."

So expect the iceberg scenario. Either in the next try they will have a fast fail if the conditions are wrong (to avoid to be discovered like this time) or the next try has already happened and we found 1/10 backdoors.

Last December I said some things like I know what I am doing and do expose my well configured private sshd for some stuff. Now I think I will hide it behind wireguard. And even that could not be good enough with some more paranoia and other backdoors. But you cannot fight them all, just make it harder.

5 Likes

Haha, yeah, I suspect we all do stuff like that. I rest a bit easier when I realize that I'm just some guy who posts on forums, and probably not the real target of the state actors who want to access various Three Letter Agency sites. Although I then think, "hmm, what if they just want to set up a botnet", then I am a target... AAAAAAHHHHH!!!

3 Likes

So what is being done to remeatate this?

What do you mean? In this exact case, OpenWrt wasn't affected.

  • OpenWrt doesn't use manually created release tarballs for xz (the ones where the build process was backdorred
  • OpenWrt doesn't make .deb or .rpm packages which were the only cases where the build script injected the binary payload
  • OpenWrt doesn't use openssh server in standard builds - it uses dropbear so the backdoor wasn't going to be active even if built
  • These packages were only in the development version, no stable version was affected
  • maintainers already downgraded xz to 5.4.6
4 Likes

Either you didn't understand the vulnerability, or you didn't read the topic start.

1 Like