@saagar Yeah, this struck me as well: it’s kind of nuts that we’re apparently fine with things like sshd loading, and being able to load, a giant unbounded ball of transitive libraries. As annoying as the way it’s implemented is, Apple’s code signing/library validation setup would have presumably prevented this, even if the payload wasn’t glibc specific? Possibly even a (say) homebrew version of sshd. (I’ve not had a chance to look exactly how the code is injected.)

@pmdj @saagar I don't think code signing and library validation would have prevented this attack. My understanding is that sshd intends to load liblzma (perhaps indirectly) and that the malicious code in liblzma is introduced by subverting the legitimate build process. No unsigned code being executed, no unauthorized libraries being loaded.

The mechanism by which code inside liblzma can interfere with other parts of sshd might be more difficult with other Apple security protections. But that might only be a speed bump, not a wall.