4 ms·

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 k

by pilif 3y ago

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.

putlake 3y ago
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?
- pilif 3y ago
  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)
ncallaway 3y ago
> 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.
- pilif 3y ago
  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.
  - woodruffw 3y ago
    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.
  - ncallaway 3y ago
    Sure, I wasn't disagreeing with your first point. I was disagreeing with your second point.
freedomben 3y ago
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)
jchw 3y ago
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.)
- hyperman1 3y ago
  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.
  - jchw 3y ago
    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!)
woodruffw 3y ago
> 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.
oogali 3y ago
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."

by pilif 3y ago

putlake 3y ago

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?

pilif 3y ago
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)

ncallaway 3y ago

> 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.

pilif 3y ago
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.
- woodruffw 3y ago
  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.
- ncallaway 3y ago
  Sure, I wasn't disagreeing with your first point. I was disagreeing with your second point.

freedomben 3y ago

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)

jchw 3y ago

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.)

hyperman1 3y ago
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.
- jchw 3y ago
  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!)

woodruffw 3y ago

> 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.

oogali 3y ago

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."