FAKE: Fedora Extras shipped popular package with rootkit and more than ten thousands systems were infected (was Re: Summary from last weeks FESCo meeting)

[Michael Schwendt]

On Thu, 01 Jun 2006 09:25:11 +0200, Thorsten Leemhuis wrote:

> Am Donnerstag, den 01.06.2006, 08:13 +0200 schrieb Thorsten Leemhuis:
> > Am Mittwoch, den 31.05.2006, 22:38 +0200 schrieb Michael Schwendt:
> 
> > But to be fair: Yes, I think it is a problem. IMHO it's currently way to
> > easy to bring in something nasty to Fedora Extras.
> 
> Just a quick howto in case if people don't know how easy it is:
> 
> 1. create a package, prepare it for review
> 2. get it reviewed and yourself sponsored 
> 3. import it and build
> 4. checkout some popular packages, upload new tarballs with a slightly
> different names and a root-kit in it. Modify the "Source0" accordingly  
> 5. commit the changes, hit "CTRL-C" at the right point of time so the
> commit-message is not send to commits-list
> 6. wait until the maintainer fixes something else in the package an
> rebuilds it without noticing the changes done to CVS in between

All fine, step-by-step instructions for any weird person out there, who
might want to try this for a bit of "fame".

I can only repeat, you are not the first one to express a paranoid view
without proposing a feasible solution.

Theoretically, it is possible with ACLs to tighten the access to "some
popular packages" in CVS. And it would also be possible to lock down the
buildsys in a similar way. Though, this would make it more complicated for
a security team.  Hey, isn't this fun? A security team which we need to
trust as they should be able to touch many if not all packages without
jumping over extra hurdles.

Package maintainers ought to make sure they cvs tag only those files in
their working copy which they agree with. The majority of package
maintainers probably never runs "cvs up", but only commits and tags from
within a local working copy anyway. Others don't even use plain cvs too
often and cvs-import.sh full src.rpms, which can overwrite/revert changes
accidentally, too. "cvs log" does catch all commit activity, doesn't it?
So, packagers, start using it if you want to contribute a bit more safety.

> There are slightly variants that even might work better. E.g.
> 
> - have a popular package in Extras and do it with that directly (that
> the easiest solution)
> - instead of "6.": build the modified packages yourself -- chances are
> quite low that somebody will notice it
> - instead of "6.": file a bug against the package you modified with a
> spec-file patch that fixes something in the package without requiring a
> new version -- the maintainer might apply it and request a rebuild (that
> is done with the modified tarball you imported to cvs earlier)

In a more shiny world, popular packages ought to be maintained and
monitored by multiple people. The more popular, the more maintainers (and
the more monitoring from within the community, e.g. people who cvs co a
package when they see a new build or who examine cvs log and cvs diff).

Don't get me wrong. I'm not opposed to any thoughts about this. But even
if a mighty ACL implementation were available (also in the buildsys), it
would not be me who could guarantee that over time nobody would acquire
the necessary access privileges to do something nasty eventually. Look,
there are people already today who would not need to go through steps 1-6
at all if they wanted to replace a binary (!) package in the repository.