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 11:53 am (UTC)
From: [identity profile] lisanys.livejournal.com
Got to love journalistic integrity.

Hashes

Date: 2010-06-15 01:57 pm (UTC)
From: (Anonymous)
They had hashes in the release announcement (http://sourceforge.net/mailarchive/forum.php?thread_name=49E341E0.3000702%40vulnscan.org&forum_name=unreal-notify), though. I know there are indeed sometimes unannounced changes, at some organizations (likely quite rare, though, for numbered tarballs of well-known open-source projects), but this should always require some checking.

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)
From: [identity profile] robbat2.livejournal.com
The Manifest was affected, at least in the sense that it contained the hash of the bad version.
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)
From: (Anonymous)
Oh ok (I only skimmed through the bug report, and indeed focalized on comment #2...), so it was still major.

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)
ext_85396: (Default)
From: [identity profile] unixronin.livejournal.com
What a prat. He's completely failed to understand that the Gentoo ebuild system detected the substitution even when UnrealIRCD's creators hadn't yet.

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

(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)

ebuild howto

Date: 2010-06-16 10:45 pm (UTC)
From: (Anonymous)
Some resources for ebuild creation:
*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)
ext_85396: (Default)
From: [identity profile] unixronin.livejournal.com
Who was that masked man? :)

(no subject)

Date: 2010-06-15 02:59 pm (UTC)
From: (Anonymous)
Adding my support and agreement in a form of a small post as everything has been said. Or in shorter words "+1"

Stupid zdnet journalist by the way.

(no subject)

Date: 2010-06-15 07:37 pm (UTC)
ext_85396: (Default)
From: [identity profile] unixronin.livejournal.com
"We're all M$ puppets as long as we run their software.  It's just that you can actually see M$'s arm sticking out of ZDnet's ass." — Ron Echeverri, circa 1995 or so

(no subject)

Date: 2010-06-15 04:50 pm (UTC)
From: (Anonymous)
the official download of a widely distributed server product has been infected with a backdoor that gives bad guys complete ownership of the system
Who runs IRC servers as root?

(no subject)

Date: 2010-06-15 07:35 pm (UTC)
ext_85396: (Default)
From: [identity profile] unixronin.livejournal.com
[nods] That.

(no subject)

Date: 2011-01-22 04:59 pm (UTC)
From: (Anonymous)
Only people who run irc servers on windows.

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