Many discussions about open source dependencies and maintenance happened in the last month.Two posts caught my eye in the Rust ecosystem: Sudo-rs dependencie...
I think that there are some interesting thoughts, but that few of the points directly relate to the issues that actually made xz a vector.
Whether Rust is safer than C. It doesn’t really matter as regards the exploit here. The attacker had a tarball containing a malicious binary. You could have done that in a Rust software package or a C software package.
That compressors are an attack vector by virtue of being a compressor. That’s…true. One of the points I made was that xz was used in the Debian packaging process, and while the attacker didn’t attempt to leverage that in this attack, it’s still in a set of packages that are extended trust even aside from ways in which it can affect OpenSSH at runtime. But, again, it wasn’t a route that the attacker aimed to exploit. I think that the attacker probably (correctly) considered that OpenSSH is subject to scrutiny, whereas other binaries that are loaded into its memory space at runtime, especially by the distro rather than the upstream project, are not.
The build system is complicated. True. This one I think does legitimately make a valid point – the easier to understand the source code is, the more-likely that someone’s eyes see a problem. Honestly, though, I’m also kind of suspicious that there are clever ways to exploit weird quirks in various systems. The bulk of this exploit was hidden in an obfuscated binary hidden in a test binary and a script that only went out in the tarball, not the git repository, and never got reviewed. All one needed to hide in the source was enough of a hook to invoke that script. That’s…honestly, not a very high bar. I’m pretty sure that I could manage to stuff something like that without raising eyebrows, especially if I’d been committing lots of test code.
Have a large organization take over maintenance to avoid having to find a maintainer. Yeah…I dunno. It’s not that that’s necessarily a bad idea, but I’m not sure that it actually solves the problem used by the Jia Tan group. I think that if a maintainer has someone show up who wants to maintain and seems to be competent at doing so, then they’re likely to let them to do so. And remember that such an organization itself would be subject to attempts at infiltration.
Knowing whether software is maintained. I’m not sure that that would have actually produced a different outcome. If xz isn’t maintained, are people likely to stop using it? I doubt it. It works well-enough. I mean, the immediate response by distros was generally “roll back to an old version of xz prior to the Jia Tan involvement, because it worked fine back then”.
That compression algorithms should be subjected to rigorous analysis. Again, maybe so, but I don’t think that that’d include analysis of their test harnesses and packaging code, which is where the Jia Tan attack came from.
Knowing whether software is maintained. I’m not sure that that would have actually produced a different outcome.
It wouldn’t have because XZ maintainership was given to the attacker. The attacker ran an entire abuse operation using puppet accounts to manipulate the already vulnerable owner. The attacker used high level social engineering tactics and ran a long con.
I think that there are some interesting thoughts, but that few of the points directly relate to the issues that actually made xz a vector.
Whether Rust is safer than C. It doesn’t really matter as regards the exploit here. The attacker had a tarball containing a malicious binary. You could have done that in a Rust software package or a C software package.
That compressors are an attack vector by virtue of being a compressor. That’s…true. One of the points I made was that xz was used in the Debian packaging process, and while the attacker didn’t attempt to leverage that in this attack, it’s still in a set of packages that are extended trust even aside from ways in which it can affect OpenSSH at runtime. But, again, it wasn’t a route that the attacker aimed to exploit. I think that the attacker probably (correctly) considered that OpenSSH is subject to scrutiny, whereas other binaries that are loaded into its memory space at runtime, especially by the distro rather than the upstream project, are not.
The build system is complicated. True. This one I think does legitimately make a valid point – the easier to understand the source code is, the more-likely that someone’s eyes see a problem. Honestly, though, I’m also kind of suspicious that there are clever ways to exploit weird quirks in various systems. The bulk of this exploit was hidden in an obfuscated binary hidden in a test binary and a script that only went out in the tarball, not the git repository, and never got reviewed. All one needed to hide in the source was enough of a hook to invoke that script. That’s…honestly, not a very high bar. I’m pretty sure that I could manage to stuff something like that without raising eyebrows, especially if I’d been committing lots of test code.
Have a large organization take over maintenance to avoid having to find a maintainer. Yeah…I dunno. It’s not that that’s necessarily a bad idea, but I’m not sure that it actually solves the problem used by the Jia Tan group. I think that if a maintainer has someone show up who wants to maintain and seems to be competent at doing so, then they’re likely to let them to do so. And remember that such an organization itself would be subject to attempts at infiltration.
Knowing whether software is maintained. I’m not sure that that would have actually produced a different outcome. If xz isn’t maintained, are people likely to stop using it? I doubt it. It works well-enough. I mean, the immediate response by distros was generally “roll back to an old version of xz prior to the Jia Tan involvement, because it worked fine back then”.
That compression algorithms should be subjected to rigorous analysis. Again, maybe so, but I don’t think that that’d include analysis of their test harnesses and packaging code, which is where the Jia Tan attack came from.
It wouldn’t have because XZ maintainership was given to the attacker. The attacker ran an entire abuse operation using puppet accounts to manipulate the already vulnerable owner. The attacker used high level social engineering tactics and ran a long con.