![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
robbat2Those 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.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
Date: 2010-06-15 11:53 am (UTC)Hashes
Date: 2010-06-15 01:57 pm (UTC)The Zdnet article, though, is complete BS. It has nothing to do with open source (only mirrors were affected), even less with Linux (there are of course many open source programs on Windows), and antiviruses are far from infallible regarding new threats. And the Manifest did its job, so users were alerted too (and they too sure should always check the cause of digest errors before manually overriding them).
What I don't understand, though (I suppose someone talked about it somewhere, but I'm very lazy), is why the Gentoo mirrors were affected, while the Manifest was not. Surely, the mirroring system should check the Manifest, and alert the developers in case of a difference.
Re: Hashes
Date: 2010-06-15 05:39 pm (UTC)Manifest commit log.
Look at commit 1.90, where DIST Unreal3.2.8.1.tar.gz is introduced, SHA1 086708695ab75041adb1a61aaa1a86141f2548ea which is the trojaned version.
The upstream author had a local Gentoo overlay, which had a Manifest with the CORRECT SHA1. From that, he claims to have detected the change. See comment #2 with the followup in comment #8 "Oh, my local overlay had the old Manifest. Sorry for the bad information".
Re: Hashes
Date: 2010-06-16 01:30 pm (UTC)I see comment #15 states the mirrored files are checked for incorrect checksums as published in the Manifest file, so the problem is really that the maintainer did not compare with the hashes published in the release announcement, or assumed there was an unannounced change without checking. And indeed GPG signatures would ease both, but there would still be manual operations to get file signatures and check them.
I suppose there should be some tool for maintainers, which would require pasting any available upstream file hashes/signatures (or confirm there is not any), for automatic comparison, before accepting the file. The tool could also automatically check for common hash/signature file extensions (.asc, .md5, .md5sum, .sha1, etc.) and global directory lists (MD5SUM, etc.), on the upstream file server, and check them too automatically, but the maintainer should still have to paste the hashes/signatures from release announcements (limiting the risk of hash/signature replacement), and confirm if there is none (and try to get upstream to include some).
Maintainers should also download the package from the most trusted mirrors, when there is no official file server. And while this is first the task of upstream (and the UnrealIRCd developers said they didn't do it -of course, I suppose few people do it, and obviously this has nothing to do with Linux), some maintainer tool may download the file from a number of different upstream mirrors (there is already some Portage infrastructure, with the "thirdpartymirrors" file, for specifying upstream mirrors, and many are already specified), and compare the hash, at least before inclusion.
Of course, this does not change much regarding Zdnet article...
(no subject)
Date: 2010-06-15 02:12 pm (UTC)To be fair, of course, the ebuild maintainer didn't follow up as well as he probably should have... were it me, I'd have contacted the UnrealIRCD guys and said, "Hey, the hash for this tarball has changed. Did you guys push an update without changing the version?"
(Which reminds me that I need to find a "How to create/contribute an ebuild" how-to somewhere, because I want to make an ebuild for Xcoral. I don't care that it's oldish; it's fast, lightweight and GOOD, and the reason it's "old" is that because it's not chasing the Gnome/KDE bleeding edge — see "lightweight" — it only needs updating when the X API itself significantly changes.)
(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.)
ebuild howto
Date: 2010-06-16 10:45 pm (UTC)*ttp://en.gentoo-wiki.com/wiki/Writing_Ebuilds
*ttp://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1
*ttp://devmanual.gentoo.org/index.html
Re: ebuild howto
Date: 2010-06-16 11:39 pm (UTC)(no subject)
Date: 2010-06-15 02:59 pm (UTC)Stupid zdnet journalist by the way.
(no subject)
Date: 2010-06-15 07:37 pm (UTC)(no subject)
Date: 2010-06-15 04:50 pm (UTC)Who runs IRC servers as root?
(no subject)
Date: 2010-06-15 07:35 pm (UTC)(no subject)
Date: 2011-01-22 04:59 pm (UTC)