robbat2: (Default)
[personal profile] robbat2

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.

Gentoo bug 323691.

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)
From: [identity profile] robbat2.livejournal.com
See my followup to the previous comment re the Manifest. Portage detected the change when run by the upstream developer, because he had a local overlay that differed vs. our main tree. The Manifest in the tree contained the checksum of the trojan version from the day it was introduced. From the maintainer's perspective, it only ever had one checksum: the bad one.

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)
ext_85396: (Default)
From: [identity profile] unixronin.livejournal.com
Heh. :) I was intending to use it as a good test case for learning to create my own. :) But I'll check it out and report, and I'll study it and compare to my experience of building it manually from source.

...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.
Edited Date: 2010-06-15 08:12 pm (UTC)

(no subject)

Date: 2010-07-10 04:39 pm (UTC)
ext_85396: (Default)
From: [identity profile] unixronin.livejournal.com
Oh, found one problem with this: The ebuild needs a dependency on x11-base/xorg-x11 to build in the proper order on an initial empty install. I've corrected locally.

(no subject)

Date: 2010-07-10 11:57 pm (UTC)
From: [identity profile] robbat2.livejournal.com
Nothing should depend on xorg-x11 directly.
It should depend on the relevant X headers and X libraries instead.

(no subject)

Date: 2010-07-11 12:15 am (UTC)
ext_85396: (Default)
From: [identity profile] unixronin.livejournal.com
x11-libs/libX11, then? That should be both necessary and sufficient.

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.)
Edited Date: 2010-07-11 12:24 am (UTC)

May 2017

S M T W T F S
 123456
78910111213
141516171819 20
21222324252627
28293031   

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags