[sf-lug] Advantages of distro package regimes (was: flash 9 on Gutsy ubuntu 32 bit)

Rick Moen rick at linuxmafia.com
Wed Dec 26 10:04:47 PST 2007

I wrote:

> To reiterate and expand on what I said about a week ago, going outside
> your package regime to install software is something you should do only
> as an extreme last resort, and then should be very wary and careful.
> One of the things package maintainers do for you is verify and attest to 
> integrity of package contents.  If you _go outside_ the package system, 
> you need to be prepared to do the checking work that they otherwise do
> for you, e.g., acquiring the software's signing key, verifying that it's
> legitimate, checking the package's cryptographic signing, and checking
> file integrity.
> If you're not ready to do that yet, then -- really -- you should stick
> to official packages.

Lest people think I'm being unreasonable in saying that:  On December
13, 2007, post-release source tarballs of SquirrelMail 1.4.11 and 1.4.12 
on www.squirrelmail.org were found to have been trojaned[1] by an intruder 
using a security-compromised developer account to insert a remote-execution 
backdoor.  This deed was caught by a user noticing that the packages' md5
checksums did not check out.

On January 21, 1999, it was discovered that the main distribution site
of Wietse Venema's key TCP Wrappers package, ftp.win.tue.nl at Eindhoven
University, had been site-compromised and the development copy of TCP
Wrappers there had been trojaned.[2]  

No Linux distributions were affected because they and other wary
observers check PGP signatures on "upstream" source releases, and, in
fact, the compromise was detected within hours by Andrew Brown of
Crossbar Security, Inc., because he noticed that tcp_wrappers_7.6.tar.gz
was unsigned. 

The next day, util-linux development release 2.9g at that site was also
trojaned[3]: exact same outcome.

On September 28, 2002, similarly, the public ftp.sendmail.org server was
site-compromised and trojaned source-code packages of sendmail 8.12.6
were offered there -- probably not PGP-signed -- for eight days.
Shortly before that, around July 30, 2002, the same thing happened with
the OpenBSD Foundation's ftp server and hosted packages of OpenSSH
3.2.2p1, 3.4p1, and 3.4 development source code.  This trojaning was
caught and corrected in about a day; as in all the other cases,
source-code downloaders who _check package signatures_ weren't fooled.

On November 5, 2003, the public copy of the Linux 2.6 kernel head code
on CVS gateway kernel.bkbits.net was trojaned by an intruder for several
hours.  Larry McVoy discovered[4] this compromise within an hour or two 
because of an alert that the checksums did not match.

You may spot a recurring theme:  Insertions of compromised code get
caught because of inclusion of gpg-signed md5 sums (or sha1sums, or
sha256sums) by the developer.  Not one of the above, rather scary,
security compromises propagated into any Linux or BSD distribution,
largely because of distro package maintainers who _actually do_ basic
security checks and don't automatically trust brand-new source code from
an upstream developer site.

However, end-users who deliberately go outside their distros' package
regimes to install new goodies are very likely to get burned:  What you
install may well not be what you think it is.  You may install corrupt
software -- are you _sure_ the Adobe flash binary installer with the
unverifiable md5sum is really from Adobe? -- and you may give unknown
distant bad guys control of your machine.

So, I'd advise not doing that -- and, in particular, not installing
"cool little Web apps" available only as tarballs you have no reason to
trust, written by unfamiliar people you have no reason to think know
what they're doing.

[1] http://lwn.net/Articles/262688/  (Article is currently subscriber-only,
    becomes readable by non-subscribers tomorrow.)
[2] http://www.packetstormsecurity.org/9901-exploits/tcpwrapper-backdoor.txt
[3] http://seclists.org/lists/bugtraq/1999/Jan/0303.html
[4] http://kerneltrap.org/node/1584

More information about the sf-lug mailing list