[PLUG] Everything you wanted to know about Linux security and aren't afraid to ask (was: Linux /Windows virus appears)

[Jeme A Brelin]

On 9 Jun 2002, D. Cooper Stevenson wrote:
> Please help me set my mind at ease on the Linux security thing. 

Uh... ease?  How about "easier"?

> While it is true that Linux built with security in mind from the start
> (file/group permissions, e.t.c.) an that (I believe) having the source
> code open for peer review are good things, it is the human element of
> the security picture that scares me the most:
> 
>     1) User receives an email from a cracker posing as a friend. The
> sender instructs the user to save the attachment and run it... ``it's
> a hoot, '' the cracker says in the message, ``you'll love it!''
>     2) User saves attachment in his home directory and runs it.

OK.  Stupid user, but OK.  Let's say that happens.

>     3) Script (or binary) performs the following:
>        find / -name -exec rm -rf {} \; 2>/dev/null
>     4) The script dutifully goes out and deletes every file that the
> user has write privileges to including /tmp.

I get the drift.

>     5) The machine comes to a screeching halt (or at least it's
> applications relying on /tmp do). The administrator is in a disarray of
> what happened.

No.  Not at all.  The user loses his homedir and maybe some other stuff on
the system is lost, but I can't imagine a single service that would
screech to a halt due to this command.

Your example of /tmp is flawed because tmp has (or should have) the sticky
bit set so that only the user who created the file can mv or rm it,
regardless of other permissions.

> Let's suppose further that our hapless user is a member of group
> ``sales.'' Under this scenario, not only would the user's files be
> deleted, but also the files and directories he has write permissions
> to in the sales area, also.

Again, your friend the sticky bit could save you.

> ``That can't happen,'' you might be saying, ``We will execute the
> equivalent of the `file' command on each file as it passes through the
> mail server.'' We will allow only documents through.

That's not why it can't happen.  And, of course, scripts can be
transmitted and executed all kinds of different ways.

> Okay, fine. The trouble is that email is not the only way to get a
> file onto the system. Like so:
[snipped example of exploit]
> I've actually had a case like the one above. It exploited a hole in
> DNS. It was incredible. It came in, dropped the source code in /tmp,
> and compiled it's payload into a binary. The compiled code was
> designed to go out to an irc channel and wait for it's author to type
> in a codeword. Meanwhile, perhaps other thousands were listening there
> as well.

Yeah, irc drones are pretty common.  You can bring your likelihood of
experiencing buffer overflow attacks and the like by running a non-x86
hardware architecture.  These kinds of attacks require the injection of
machine instructions into a process stack (usually through a public
network port).  If your machine doesn't run x86 instructions, the cracker
doesn't get his desired effect.  In some cases, the service will go down,
but no malicious code is run locally... and if you've got any kind of
service watchdog daemon, the blip might be no big deal.

> The believe it was designed to destroy files.
> It happened on my security officer's home machine. He sent it to me
> and I analyzed it. It was written in C.
> I'm worried.

I'm worried about two things:

Admins ignore user education (often they think of their users as "idiots"
or "lusers" and put poor effort into their training in order to maintain
their own feeling of superiority).  We know better than to do certain
things (like give our passwords to other people or run code we haven't
inspected or had inspected), there's no reason why your mom an dad and
brother can't learn the same simple precautions.

Diversity of architecture is poor (being divided mostly between Windows
and Linux on x86 with *BSD on x86 and Solaris on Ultrasparc coming up
behind in distant third and fourth).  A large computer network is a lot
like an ecosystem: destructive organisms have the most drastic effects
where diversity is low.

J.
-- 
   -----------------
     Jeme A Brelin
    jeme at brelin.net
   -----------------
 [cc] counter-copyright
 http://www.openlaw.org