Those that have followed me for a while might have seen me previously complain at journalism that's misleading, wrong, or outright fictitious. Now I've got another case...![]()
This article by Ed Bott at ZDNet:
Linux infection proves Windows malware monopoly is over; Gentoo ships backdoor? [updated]
The article was first published 2010/06/12 20:37 UTC.
It claims to be "worse" when updated at 2010/06/14 19:30 UTC.
Gentoo had a revision bump to a known good copy of the tarball at 2010/06/12 16:34 UTC (using a different filename, and verified against the GPG signature provided by upstream), so it was ALREADY fixed when the article was published. The old revision was explicitly removed at 2010/06/12 21:18 UTC.
Commit data for fixes:
Changes for unrealircd-3.2.8.1-r1.ebuild
Changes for unrealircd-3.2.8.1.ebuild
The trojaned tarball was then removed from the Gentoo master mirror at 2010/06/13 08:00 UTC, about 11 hours after the article was published. It would have been sooner, but it was a matter of bad timing.
The article also claims: "There’s a great deal of comment in the Talkback section of this post about how official repositories can be trusted. It appears that system broke down thoroughly in this case."
This claim is bogus. The developer that updated the package made perhaps a mistake in trusting that the upstream had not been tampered with. However, in lacking anything to verify against (the upstream apparently did not sign releases at that point), he couldn't have detected the backdoor except by manual inspection of all the code. He downloaded the package AFTER it had been tampered with (2009/11/11 I believe), so he never saw the tamper-free version either.
The entire point of the Gentoo Manifests are to ensure that OUR mirrors are not the point where a compromise is introduced. We can detect upstream changes by this same mechanism, but they mostly tend to be upstream deciding to 'fix' something without bumping the version number. In this regard, they functioned perfectly.
P.S. I'm not saying the existing Gentoo mirroring is perfect either, see my prior writings on tree-signing, and the "Attacks on Package Manager" papers by Cappos et al., which are blocked only with the full tree-signing system.
(no subject)
Date: 2010-06-15 06:12 pm (UTC)If we detect a tarball changing, we usually either diff it for manual inspection or ask upstream. Inspection is usually much faster.
Xcoral:
http://git.overlays.gentoo.org/gitweb/?p=dev/robbat2.git;a=commit;h=a48a3491815b45873e24c1bdcc5968b52fcfc154
Test it out, and if it's all good, I'll merge to the main tree.
(no subject)
Date: 2010-06-15 07:34 pm (UTC)...Looks to be working fine. Clean build with no issues, it Just Worked. The one suggestion I would make is to install the manual and quick reference card from xcoral-3.47/Doc into /usr/share/doc/xcoral-3.47.
(no subject)
Date: 2010-07-10 04:39 pm (UTC)(no subject)
Date: 2010-07-10 11:57 pm (UTC)It should depend on the relevant X headers and X libraries instead.
(no subject)
Date: 2010-07-11 12:15 am (UTC)Actually, I'll have to test ... x11-libs/libXaw may be required too. I'll find the minimal set and let you know.
(DOH! ldd is my friend, when I'm thinking. It links with x11-libs/libX11, x11-libs/libXau, x11-libs/liblibXdmcp, x11-libs/libxcb. The latter three are all dependencies of libX11 though. So, yeah, just x11-libs/libX11 will do it.)