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:
<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...
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?
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?
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.
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.
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!!!
OpenWrt does not use systemd and a patched OpenSSH, which does not mean that either systemd or OpenSSH are at fault but this is one way how the backdoor was built.
The xz 5.6 backdoor payload activated when the running process has the name /usr/sbin/sshd. Our OpenWrt default sshd has the name /usr/sbin/dropbear.
OpenWrt is not be affected from my point of view. The reaction and the mitigation of this backdoor was quick and effective.
The bigger question for me is how to proactively hamper future more sophisticated supply chain attacks that may stay unnoticed for longer time.
