One more thing:
Is anyone on the Debian side trying to figure out how far we've been practically affected? I mean let's assume we're "lucky", and the backdoor is only in 5.6.0/5.6.1... and that none of the adversary's earlier commits introduced any serious holes[0] which wouldn't be known yet. Then many servers running Debian (which is then typically Debian stable), would be sill safe. However, many people (and I'd guess that includes DDs/DMs) run their workstations/laptops with testing/unstable. So IMO it's not enough to know that Debian stable is likely not affected - I'd be rather relieved if I'd knew that there's a good chance that the personal computers of most DDs/DMs (who push uploads, etc. pp.) were (at least practically) safe. Some guy decrypted[1] the strings from the maleware's binary payload: https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01#file-hashes-txt-L115 where only /usr/sbin/sshd would be named. Should(!) it turn out, that the actual binary payload actually only affects sshd and especially does not on it's own pull in evil code, it might at least be that all people who hadn't sshd running (or not directly accessible because a router/firewall/etc. was in front of it), would effectively still be safe. No idea whether or not this is really the case - but if so, it might at least mean that many workstations/laptops are safe, because they're not usually directly accessible from the internet. But even then, it would probably need to be checked whether all the versions that Debian ever used/shipped in testing/unstable(/experimental) were actually fully identical to the versions that are now analysed by forensic folks. Is the security team doing anything like that? Cheers, Chris. PS: if someone from the security team reads along, https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27 which is from Sam James of Gentoo, seems to collect good information on what is known so far. Might be worth to add to the links in the security tracker. [0] There are reports about an added '.' in the CMakeLists.txt disabling some sandboxing, but AFAICS at least the current version uses autotools for building?! [1] He also provided the code he used to do so. https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01?permalink_comment_id=5006546#gistcomment-5006546
