While this is great news, in my opinion, given the facts surrounding this backdoor, I think this article is misguided due to two reasons:
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.
Re 1., we know because we are developers but managers and other less technical folks involved in software development want to know whether it's safe to use things, even if SSH is not involved.
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.)
I prefer not to refer to 'the' XZ backdoor, because people are under pressure to declare this over. This imprecise way of talking allows management to say ssh is secure, so the backdoor is fixed, so stop spending time and money looking deeper into this. Meanwhile, other potential xz backdoors might fly under the radar.
Well, for all intents and purposes, it is over for the security issue that is disclosed. Even if people continue investigating further potential issues and rolling back potentially innocuous changes out of an abundance of caution, there's genuinely nothing else for consumers of liblzma5 or xz to do directly, unless they want to participate in that investigation.
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!)
Engineering managers and their managers are not all technical enough to know if RubyGems is vulnerable, but nonetheless are often technical enough to know that RubyGems is used by them. I'm not posing a hypothetical here, I've already seen management asking similar questions.
The flip side is companies that are not active participants in the open source community (but know they use open source), are pinging all their engineering managers and asking "are we exposed to this!? how do you know!?".
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."
> 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.
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.
Not commenting on the applicability to the RubyGems post, but just in general point number 2 is something I've been thinking of as well. If I were going to undertake a long-term effort like this to compromise, I would not have put all my eggs in one basket. We might only have discovered 1 of 3 and should not be celebrating yet (though a congratulatory toast is very appropriate)
Completely disagree. Every project that has xz/liblzma added as a dependency should be looking at the source, compiling from said source and making sure their binaries that they shipped with their software match this. For example, homebrew should do this. If the attacker configured the backdoor for the server to enable a universal master key, who's to say they didn't engineer a backdoor for the Homebrew version to export private keys from the current user's .ssh folder?
That's my second point. Just checking for version <= 5.6.0 is not safe either and is exactly what the original article has done.
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)
> it's too early to claim that a project is not vulnerable to backdoors
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.
That's my first point though. If you only take into account what is currently known about the backdoor, unless you are a linux distro building a liblzma debian or RPM package, you are not vulnerable to the backdoor.
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.
Much like PyPI, there are a large number of gems on RubyGems that either vendor library builds or provide source redistributions for local builds. That’s why these kinds of indices need to perform these scans; it’s not sufficient to assume that the host distribution or OS is the only source of runtime libraries.
"As verified by running find / -name 'lzma' in our built containers, we depend only on version 5.4.3 and not on the vulnerable versions 5.6.0 or 5.6.1."
Yet Debian is looking into reverting to 5.3.1, as all newer versions contain many commits by Jia Tan.
Arch has a policy to keep package patching to a minimum. If the newer xz version doesn't have a backdoor, they will probably follow upstream.
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.
> This thread had been meant to call attention to the official announcement. I think it is clear systems should be updated out of caution. This thread has diverged from that point.
> 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.
no. We have to assume any commit of the threat actor to have been malicious. Given that 5.4 contains code by the threat actor, it's not safe to claim to not be vulnerable. Not vulnerable to this specific backdoor, sure. But I don't feel like 5.4 is safe either.
Having done this, it’s not worth the effort to implement if you using more than a handful of gems and a handful of gems is really easy to inspect using diff.
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.
I think what GP is getting at, and is something I've hit as well in the past when auditing diffs, is that it's just not feasible. For a small project maybe, but for a medium to large Rails app for example you would need to dedicate potential multiple full time engineering to do nothing but review diffs. Things change fast, and a lot of the changes are not simple patchsets you can eyeball. Without some domain knowledge and even context such as "did they just refactor or is this a total rewrite" it can be very difficult to even understand what you're reading without a bunch of extra work. At a minimum you need to read the commit log in addition to the diffs.
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.
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.