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

[Anthony Schlemmer]

You don't even need a virus to get step 3 to occur. I'm man enough to 
admit to the fact that I accidently "rm -rf'ed" my home directory off 
of a system at work one time. Thankfully we had a great SA that had our 
server setup to take nightly backups of our home directories so I 
didn't lose anything. 

As a longtime user of Unix it took me 16 years before I ever made that 
sort of Unix mistake. I'm not sure I'll ever live that "uh oh" down. 
Our SA ribbed me about it for a while although he said it's not the 
first time he's seen someone do that.

Hanging my head in shame,

Tony

On Sunday 09 June 2002 10:42 am, D. Cooper Stevenson wrote:
> All;
>
> Please help me set my mind at ease on the Linux security thing.
>
> 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.
>
>     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.
>
>     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.
>
> 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.
>
> ``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.
>
> Okay, fine. The trouble is that email is not the only way to get a
> file onto the system. Like so:
>
>     1) The cracker social engineers the user name and password on the
> system.
>
>     2) The attacker launches a script that utilizes a known remote
> exploit on the server.
>
>     3) The script drops the executable in /tmp , su's to a known user
> name (if it is not already working as that user), and runs the
> equivalent to the `find' command above.
>
> 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.
>
> 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.
>
>
> -Cooper
>
>
> _______________________________________________
> PLUG mailing list
> PLUG at lists.pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug

-- 
Anthony Schlemmer
aschlemm at attbi.com
>>>>This machine was last rebooted:  12 days 19:14 hours ago<<