RubyGems is not vulnerable to the xz/liblzma backdoor
blog.rubygems.org
blog.rubygems.org
1. the scope of the known backdoor is very constrained to only be inserted into native OS packages. As such, I don't think we need every other user of liblzma to post blog posts that they are not vulnerable independently of which version they embed. This is at best noise and at worst dangerous because
2. the bad actor has been submitting patches to liblzma for much longer than the 5.6 release and given the ingenuity of the attack, it's too early to claim that a project is not vulnerable to backdoors simply because there might already have been other "presents" left by the threat actor.
Given these two points, I really believe we should not be posting "hey we are not vulnerable" blog posts here because at best they are useless noise (nobody aside of debian or redhat and their downstreams is vulnerable) and at worst false assurances.
But if all you use as the basis of the vulnerability analysis is the version constraint and what we currently know about the backdoor, then, unless you are a distro building a liblzma distro package, you will not be vulnerable no matter the version (which was my point 1)
I don’t think that’s a fair or accurate paraphrase of the blogpost.
They said they weren’t exposed to the backdoor (headline), or this issue (body of article). Both are deliberately singular, and from context clearly referencing the known back door.
I don’t see anything in the post claiming they aren’t vulnerable to back doors in general.
So I believe, given the current state of knowledge, that all the projects that are not about building liblzma packages are not vulnerable and thus their postings about them not being vulnerable is noise.
Re 2., I honestly agree, but I think it's fair to refer to "the XZ backdoor" as the one we know about vs. the potential ones that we don't know about yet.
I also kind of think "we are not vulnerable" might inspire unwarranted confidence. The real answer also needs "(but honestly, we totally would've been if it targeted us)" but this creates a lot of fear that isn't going to help much. (Hopefully though, the existing fear and paranoia created by this attempt will help us push assurances a bit further. I feel the OpenSSL exploits definitely helped push some things forward, too, even if the world is clearly not perfect after all of that.)
But, for users of xz, like package managers, I think the right thing to do is sandbox all of the compression (and other data handling routines) using OS-level sandboxing technology like seccomp and pledge if they don't already. It's already a common strategy for handling potentially unsafe data, and while packages are typically signed and could potentially compromise the system anyway if not trustworthy, it's still worth it because a compromise via RCE in the LZ algorithm could possibly be VASTLY more difficult to detect than the package itself being malicious, in the same way that compromising SSH via a library it doesn't even nominally depend on is. (e.g. a package could potentially detect if it is being unpacked manually or via a package manager to try to hide that it is malicious!)
A "didn't happen to us" is noise because it could have happened for a different actor/target.
Nobody has said this. The post says specifically that nothing on RubyGems is known to use the known backdoor; nobody has made (or could reasonably make) claims about unknown future backdoors. It’s incumbent on you to understand that this kind of announcement doesn’t imply the absence of potential future ones.
So while it's useless noise to you, it's likely triggered by being on the receiving end of communications like "Hey, my boss is asking if $PROJECT is vulnerable because of a terrible article he read in $MAINSTREAM_MEDIA_PROPERTY?" times however many bosses are harassing their reports.
"I don't want to craft an email reply to every single person, just put up the no-op blog post and be done with it."
Yet Debian is looking into reverting to 5.3.1, as all newer versions contain many commits by Jia Tan.
Don't Arch Linux also want to get rid of those suspicious commits?
Also, Arch doesn't appear to be affected by the vulnerability:
>> openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma.
> Arch does not directly link openssh to liblzma, and thus this attack vector is not possible.
> I am going to go ahead and close the thread at this point.
It seems that discussing further mitigation steps is off topic in that thread. Unlike Debian and NixOS, Arch Linux devs don't appear to want to downgrade to 5.4 to get rid of code authored by the malicious developer.
And bundler isn’t aware of external C libraries you’d need to inspect.
Auditing tools using a database of known vulnerabilities is the only scalable solution I know of.
Personally, this is an area where I think AI could add a huge amount of value. An AI tool that looks at your gem versions (or node or elixir, whatever) and then reads all the commits that changed and reviews them for safety/security and maybe summarizes them, could be huge.