Re: Debunking the "Linux can't have viruses" myth ...

From: Rick Moen (rick_at_linuxmafia.com)
Date: 11/23/04 

Date: Tue, 23 Nov 2004 21:22:24 GMT

Jon Gomez <jon.gomez.04@cnu.edu> wrote:

> I recently tried chrootkit based on its praise from people here. According
> to the instructions, it requires root access... so I ran it as root. I
> could not help feeling a little paranoid, considering the context, that I
> was exposing my system.

1. Paranoia's a good place to start. ;->

2. When you decide to trust something, one of the things you should
(and probably do) consider is: Where did I get this from?
Which reminds me: Where _did_ you get your copy of chkrootkit from?
If you thought "That chkrootkit thing sounds worthwhile", googled for it,
and retrieved a tarball from http://www.chkrootkit.org/ , then that was
sub-optimal, and let me tell you why:

Your distribution has package maintainers. They serve some very valuable
purposes: They customise each package, as necessary to make it work
well with your distribution. They are a second level of check for
quality or security problems. They verify the upstream tarball's PGP
signature, to make sure it hasn't been trojaned or replaced. And they
then provide package files whose integrity of transmission (from the
package maintainer) you can trust using your distribution's
package-checksum tools.

So, unless you have a specific reason for distrusting your package
maintainer, most of the time you increase your confidence in the
software rather than decreasing it, by installing the packaged version
rather than fetching a tarball from upstream.

If you _do_ fetch a package from upstream, you need to perform for
yourself the checking tasks ordinarily performed by the packager on your
behalf: You would want to check the tarball using the coder's known
crypto signature, for example.

> For example, what if it had been hacked like the smoothwall site, but
> more subtly and someone had dropped something malicious in the
> codebase?

I'm not familiar with the incident you're referring to: Googling for
sundry variations on "smoothwall site" and "compromise" turns up
nothing relevant. However, I _can_ discuss, by way of example the
incidents involving ftp.win.tue.nl . That's a university ftp site at
Eindhoven University.

On January 21, 1999, Crossbar Security, Inc. researcher Andrew Brown
downloaded the then-current tarball (v. 7.6) of Wietse Venema's TCP
Wrappers package, which at the time used ftp.win.tue.nl as its primary
distribution site. (Given that TCP Wrappers is a security-sensitive
package, it would logically be a prime target for intruders.) Brown
_did_ bother to check the package signature: He found that it was
_unsigned_, and correctly became suspicious. Further scrutiny confirmed
that the package was trojaned and had been uploaded a few hours before
by (obviously) someone who'd compromised ftp.win.tue.nl site security.

The next day, John Stange of the University of Maryland CS staff
downloaded the apparently latest util-linux package (v. 2.9g) from the
same site, noticed the same suspiciously missing signature, and likewise
found that it had been trojaned. This package compromise, too, was
detected within hours of upload. The couple of dozen sites that had
(per the logs) downloaded the two packages were notified, and the site
was rebuilt.

My point is that the trojaned versions, even though they probably
snagged some unwary random members of the public who grabbed upstream
tarballs in order to get the newest and latest -- and who hasn't (unlike
Brown and Stange) bothered to check PGP signatures -- the compromised
software didn't penetrate any Linux distributiosn for two reasons: (1)
Lack of passage of time. The trojaning was detected and terminated
before even any _reckess_ Linux distribution maintainers (if any) could
package and re-release them to the public. (2) Wariness. We _hope_
(at least) that distro maintainers will exercise at least as much due
diligence about upstream alleged releases that Brown and Stange did.

> I know many people don't have the time or skill to personally read
> through every piece of code, so they are required to be on a
> trust-based relationship.

Correct. So, choose whom you trust as your gatekeeper, accordingly.
And then try not to sabotage the system with bonehead errors. ;->

(And, hey, some days you just can't trust anybody: Try googling for
"Reflections on Trusting Trust" to read about Ken Thompson's mindblowing
exploit that he pulled over on, well, everyone.)

> Besides, if linux is going to be used by the general populace, including
> people who are stunned by mouses with different number of buttons, rather
> than just by those with technical skills, we should probably assume,
> defensively, that there will be plenty of idiots. So is there anything we
> can do to try to make linux more idiot-proof? (as opposed to more secure)

Coders and packagers make a reasonable effort to make the safe way the
easy way, and the easy way the safe way. Beyond that, we have to just
keep educating people to stop shooting at their feet, and to think twice
before (1) doing anything at all as root, and (2) executing software
that they have little or no reason to trust.

Quantcast