The tar file in my distfiles dir md5sum's the same as the trojan'd version. Reproducible: Always
+*unrealircd-3.2.8.1-r1 (12 Jun 2010) + + 12 Jun 2010; Samuli Suominen <ssuominen@gentoo.org> + +unrealircd-3.2.8.1-r1.ebuild: + Revision bump wrt security #323691.
The unrealircd taball in the gentoo mirrors _is_ affected ( Unreal3.2.8.1.tar.gz ) but the Manifest file's signatures match the _unaffected_ tarball. This discrepancy is how the backdoor was discovered. So, please just flush the tar.gz from gentoo's mirrors, teach people to not blindly run ``ebuild *.ebuild manifest'', and unrealircd's SRC_URI does not include the current upstream tarball location: SRC_URI="http://www.unrealircd.com/downloads/${MY_P}.tar.gz" (unrealircd's mirror system was compromised by the attacker and so the tarball is temporarily being hosted at the official site).
A system() call was injected into the tarball, disguised as a debug macro that would be called with the contents of the read buffer under certain circumstances. Rating B1 as Remote active compromise of the "unrealircd" user.
(In reply to comment #2) > The unrealircd taball in the gentoo mirrors _is_ affected ( > Unreal3.2.8.1.tar.gz ) but the Manifest file's signatures match the > _unaffected_ tarball. This discrepancy is how the backdoor was discovered. > I cannot confirm this with a tree dated Tue, 08 Jun 2010 20:30:20 +0000.
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-irc/unrealircd/Manifest?revision=1.95&view=markup SHA256 45264abc6c4aaaa132ea735fb90aaf43185950825f0b947d6e0f6210c6e3e7c8 $ sha256sum Unreal3.2.8.1.tar.gz 45264abc6c4aaaa132ea735fb90aaf43185950825f0b947d6e0f6210c6e3e7c8 $ md5sum Unreal3.2.8.1.tar.gz 752e46f2d873c1679fa99de3f52a274d ^^^ The backdoored copy in both Manifest and file downloaded from http://mirrors.kernel.org/gentoo/distfiles/Unreal3.2.8.1.tar.gz to distfiles/
*** Bug 323711 has been marked as a duplicate of this bug. ***
Sorry for the dup, idl0r and me are currently driving back home and the net in the car is a bit flaky and we wanted to report this fast (no search, sorry).
(In reply to comment #4) > (In reply to comment #2) > > The unrealircd taball in the gentoo mirrors _is_ affected ( > > Unreal3.2.8.1.tar.gz ) but the Manifest file's signatures match the > > _unaffected_ tarball. This discrepancy is how the backdoor was discovered. > > > > I cannot confirm this with a tree dated Tue, 08 Jun 2010 20:30:20 +0000.\ Oh, my local overlay had the old Manifest. Sorry for the bad information :-/
Suggesting a label of CRITICAL here. The ebuild needs either to be masked or the Manifest redone AND ALSO the mirrors need to get rid of the infected copy and fetch a new copy The correct checksums are MD5: 7b741e94e867c0a7370553fd01506c66 SHA1: 363c3c995bb38cf601f409610ce1937a0002c419 or use the new gpg keys Syzop made few hours ago. I am as well as ohnobinki a member of the official UnrealIRCd team. Upstream is currently not planning to do a version bump themselves.
and sorry for showing up late to the show just been reading the other comments. ignore my dup comments please
(In reply to comment #9) > Suggesting a label of CRITICAL here. > This issue is rated correctly as per the Gentoo vulnerability policy. > > The ebuild needs either to be masked or the Manifest redone AND ALSO > the mirrors need to get rid of the infected copy and fetch a new copy > I'm sure you mean well, but we're not dealing with our first security issue here. We (Gentoo Security) have discussed the issue and are taking the necessary steps. Thank you.
+ 12 Jun 2010; Alex Legler <a3li@gentoo.org> -unrealircd-3.2.8.1.ebuild, + unrealircd-3.2.8.1-r1.ebuild: + Security commit: Copying stable keywords from 3.2.8.1 to 3.2.8.1-r1. The + source tarball differs only in the backdoor which is removed. Removing + vulnerable ebuild. Reference: bug 323691 + As an additional measure I have asked infra to remove the affected tarball from the master distfile mirror. I want to point out that this is *not* standard procedure and only done as there seems to be a certain buzz about this issue and there won't be peace until every copy of that tarball is removed. GLSA request filed.
GLSA 201006-21
As infra, I wanted to explicitly note that the compromised tarball was zero'd as of 2010/06/13 08:00 UTC. The ebuild was updated to use a different filename as well 'Unreal3.2.8.1-notrojan.tar.gz', which validates against the upstream .asc.
@Alex: future reference, if the chksum info in the manifest differs from what is currently on the mirrors, what's on the mirrors will get wiped automatically and refetched. Mirror updating is something like once every 4 hours...
Based on the facts below, I assume that either Tomás Chvátal <scarabeus@gentoo.org> remarked that the hashes did not match on early Sat Nov 14 of 2009, and did not have time to investigate enough, or that his account was intentionnaly owned at that time. The Manifest with evil hashes was uploaded on 2009-11-14 01:34:44 according to http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-irc/unrealircd/Manifest?revision=1.90&view=markup The ebuild unrealircd-3.2.7 (stable at that time) was removed on 2009-11-14 01:34:35 according to http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-irc/unrealircd/unrealircd-3.2.7-r2.ebuild?view=log A comment talking about an unnamed and unknown security bug of unrealircd-3.2.7 was posted on 2009-11-14 01:36:15 at http://bugs.gentoo.org/show_bug.cgi?id=260806#c16 All these three activities were done with the account of Tomás Chvátal <scarabeus@gentoo.org>
(In reply to comment #16) > Based on the facts below, [..] Uhm, the problem was upstream, and no Gentoo developer accounts were compromised or anything. Anyway, it's fixed now, so there's nothing left to worry about. > A comment talking about an unnamed and unknown security bug of unrealircd-3.2.7 > was posted on 2009-11-14 01:36:15 at > > http://bugs.gentoo.org/show_bug.cgi?id=260806#c16 Sorry, I don't see what you're talking about.
(In reply to <A HREF="show_bug.cgi?id=323691#c17">comment #17</A>) > Uhm, the problem was upstream, Not precisely : the unrealircd-3.2.8.1.tar.gz was only compromised on sites mirroring the upstream sources, not on the upstream site itself. I thought that the concept of Gentoo's Manifest was precisely to block such compromises. > and no Gentoo developer accounts were > compromised or anything. Anyway, it's fixed now, so there's nothing left to > worry about. I know that, in this case, the compromise was uncovered, seven months later. What bothers me is that Gentoo seems not to be immune to similar attacks. > (In reply to <A HREF="show_bug.cgi?id=323691#c16">comment #16</A>) >> A comment talking about an unnamed and unknown security bug of unrealircd-3.2.7 >> was posted on 2009-11-14 01:36:15 at >> >> http://bugs.gentoo.org/show_bug.cgi?id=260806#c16 > > Sorry, I don't see what you're talking about. I am talking about "3.2.8.1 with required QA touches added to main tree. Removed the old affected version." Next comment showed that this action was not appropriate: "the old ebuild with stable keywords has accidentally been removed". I think this action might be suspicious.
(In reply to comment #18) > I thought that the concept of Gentoo's Manifest was precisely to block such > compromises. > The file was compromised *before* it entered the Gentoo system. There is nothing more to be discussed on this particular bug. If there are further inquiries please direct them to the appropriate contacts via email or mailing list. Thanks.
(In reply to comment #18) > (In reply to <A HREF="show_bug.cgi?id=323691#c17">comment #17</A>) > > Uhm, the problem was upstream, > > Not precisely : the unrealircd-3.2.8.1.tar.gz was only compromised on > sites mirroring the upstream sources, not on the upstream site itself. It was compromised on upstream's mirrors, and thus the problem was upstream (Why else would upstream have made an announcement?). Gentoo's ebuilds fetch from there. > I thought that the concept of Gentoo's Manifest was precisely to block such > compromises. Yes, if the Manifest had been generated *before* upstream was compromised. > I am talking about "3.2.8.1 with required QA touches added to main tree. > Removed the old affected version." > > Next comment showed that this action was not appropriate: "the old ebuild with > stable keywords has accidentally been removed". I think this action might be > suspicious. Heh, I see your point. But that was just coincidence, human errors happen.
