3 ms·

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 thin

by 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!)
karmakaze 3y ago
If you're using ruby gems you're a developer and should know the diff between an os package and language lib. And this is Hacker news. A "didn't happen to us" is noise because it could have happened for a different actor/target.
- jchw 3y ago
  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.

by jchw 3y ago

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

karmakaze 3y ago

If you're using ruby gems you're a developer and should know the diff between an os package and language lib. And this is Hacker news. A "didn't happen to us" is noise because it could have happened for a different actor/target.

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