Aliyaut’s logo? It is clean, but it’s hardly even identifiable as a gecko. It blends in too much with all the modern corporate logos we have today IMHO. It’s not a bad choice if they decide to go with it, but they could do better.
A recent example is that reproducible builds allow for the creation of proof, simply by rebuilding and comparing the result, that a GCC build whose source was extracted with a compromised xz was not compromised; this process was achieved without needing to reverse engineer how the compromise occurred. Similarly, reproducible builds were reported as being usefully during investigations of the xz compromise.
As much as I love openSUSE, and reproducible builds are a core requirement for trusted computing…
reproducible builds were reported as being useful
Really buries the lede of the xz attack results
either both are trojaned, or none
Edit: It is very useful for the first half - to ensure new packages extracted by a compromised xz weren’t modified during the extraction.
It’s just that reproducing the build of the tampered xz would still produce a bit-for-bit identical compromised version due to the way it modified the build system
Honestly i barely even pay attention to this stuff, because backdoors like this probably make it into production on closed source projects daily. Its impossible to always know and prevent everything, but open source is the only way that even attempts to do so.
If anything this is a testament to how open source is the only way to make secure IT infrastructure.
This was obviously a nasty, weird situation but the public accounting and open reflection on it all is demonstrating one of the main strengths of open source software.
If you run a rolling release distro, or one that tends to ship more updated packages, you may need to check up on this and make sure you’re not using the compromised versions of the xz compression library.
Here is a site detailing the current known history of how the malicious exploiter got access to the repository and what he had pushes to it.
Side note for Arch (btw) users: If you run xz --version, it will report to be version 5.6.1, even if it’s the updated version. This is because the updated and presumably safe package is xz 5.6.1-2.
The backdoor didn’t really affect Arch, because it only compromised SSH when it was linked against liblzma, which is a requirement for libsystemd. However, Arch doesn’t link it that way, so it’s safe to use. You should still update though, because we don’t know if the backdoor could be used in any other way.
graphviz: Exploitability for CVE-2023-46045 may be uncommon because this file is typically owned by root, but is related to an out-of-bounds read via a crafted config6a file. A welcoming fix was provided.
I can’t imagine a single reason to use graphviz other than legacy code. Its algorithms are classical and old. Maybe someone should rewrite it in Rust, but even that might be an overkill.
It would also be interesting to know if any OS was in feature freeze recently that is not supposed to get updates anymore. I was thinking about Android, OpenWRT or any of those where people update update their devices more rarely
OpenWRT does not use liblzma or systemd so i think that one is pretty safe. I would also be surprised if Android included OpenSSH server binaries in that way.
It’s quite interesting to see that the developer who has embedded the backdoor “simplified” the SECURITY.md file just 4 days ago, by deleting information about how to report a security vulnerability.
The reason it’s really interesting is that if I understand it right, the backdoor was just discovered less than a day ago.
So this is what happens when package maintainers fail to find the problematic bits during package updates. I’ll be honest, after seeing how Linux package management is done (automation and semi-automation galore) and by whom (people who often don’t know the programming language of the source and who don’t have much time either), I am more surprised that it took this long.
In this case the upstream maintainer heavily obfuscated the code to be able to compromise ssh. Package maintainers aren’t responsible for vetting for that.
The original email talks about a line that is in the release tar balls but not the repository itself that actually arms the exploit. This seems like something a maintainer should be able to verify.
Not saying that they should have immediately seen that that is an exploit, the exploit is obfuscated very well. But this should be a big red flag right?
As a Homebrew maintainer, what is there to red flag about a project providing tarballs of their source?
We would have to red flag pretty much every project that uses autoconf (since those usually provide a tarball where the user doesn’t have to run autoreconf)
I have to admit I have no practical experience as a package maintainer, but this case sounds like there is a diff between files checked into the repo and the ones provided by the tarball.
If the tarball contains new files that contain executable code that’s still weird tbh, but I guess you have to trust the upstream maintainers to some degree. But a diff in a checked in file seems different to me.
Yes, it took a security researcher to find this out. Package manager maintainers failed, and they were whom the average Linux advocate supposed will catch the back door, whenever they boasted about the safe-ness of Linux.
On desktop systems, the SSH server is disabled by default. It should say “disabled” in systemctl status sshd, then you’re good.
On server systems, the SSH server is enabled, but you would usually know that it accepts incoming connections from the internet.
So, a home-server would need to be exposed in your modem/router. And if you’re hosting on a VPS, well, then it’s obviously going to be reachable.
It’s good that it didn’t get into Leap or Enterprise. Servers for businesses shouldn’t generally be using Tumbleweed.
It sounds like to be really vulnerable a machine has to expose SSH to the internet. So if that’s correct then most typical home computers should be safe. Based on that assumption I’m not rushing to wipe and reinstall.
What scary is the maintainer that insert the backdoor has been main maintainer for xz for the last two years. Who know if they have other backdoors inserted in the last 2 years? Investigation is still ongoing so I expect more juicy revelations in the next few days.
news.opensuse.org
Hot