[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: mail trojans in linux
- To: Shaul Karl <shaulka(at-nospam)bezeqint.net>
- Subject: Re: mail trojans in linux
- From: Tzafrir Cohen <tzafrir(at-nospam)technion.ac.il>
- Date: Fri, 7 Sep 2001 17:13:05 +0200 (IST)
- Cc: Linux-IL mailing list <linux-il(at-nospam)linux.org.il>
- Delivered-To: linux.org.il-linux-il@linux.org.il
- In-Reply-To: <E15fMPB-0000OM-00@rakefet>
- Sender: linux-il-bounce(at-nospam)cs.huji.ac.il
On Fri, 7 Sep 2001, Shaul Karl wrote:
> > Hi
> >
> > I saw the following news item in linux today:
> >
> > http://linuxtoday.com/news_story.php3?ltsn=2001-09-07-008-20-SC
> >
> > The story (from VNUnet) is about a new linux trojan. A quote from it:
> >
> > The so-called Remote Shell Trojan spreads through email as well as
> > replicating itself across the infected system
> >
> > Is there any linux mail client that doesn't make it hard to execute
> > executable attachments from mail messages? (and if so: why is anybody
> > using this mail client?)
> >
> > If not: are such trojas an issue at all?
> >
Just to illustrate this I attach a small perl script. Some of you may be
reading this mail from a windows mailer where ActiveState perl is
installed, and where the ".pl" extention is associatted with ActiveState
perl, and "opening" this attachment will be execting this script.
Hopefully no unix mailer will "open" it this way (unless the user has
actively requested this).
>
> I believe that such Trojan might be an issue, depending on the users behavior.
> A simple example would be to send you a game which will just increase the load
> of your system, without doing any real work. Although in most cases it is less
> harmful then replacing some executable with another, it is still annoying.
> I guess that more damage then this can be made, even on user space.
> In short, a UNIX machine can not replace a cautious user: Users should take
> care of the executables they are running and, (of course?) not run as root.
Too many systems have unpatched local root exploits. Allowing a remote
user to run an arbitrary command is at least half way to a root exploit.
Even without suplying a remote shell (as this "shell trojan" does).
I trust the programs in my mailcap that they are harmless viewers
(I have once verified it. I hope that I can continue to trust my distro
with the mailcap file and equivalent definitions). This means that the
worst an attached document can do is some DoS attack: consume too much
cpu/memory. I can deal with that.
Occasionally it may turn out that one of them handles the input file in an
unsafe manner. This is a security hole that is exploitable by a remote
user (the one sending me the message). One example for that is the
recently-discovered buffer overflow in xli .
>
> > [ Please avoid making this an ms-bashing thread. I hope linux program
> > authors have learned from the design mistakes of Apple and MS with respect
> > to this specific issue. A mail client should allow the user to "view" a
> > document, not "open" it. Or at least it should make a very clear
> > seperation between the two. The basic design of apple, extended by MS to
> > mail clients, does not have this distinction. OTOH unix has long had
> > mailcap. ]
--
Tzafrir Cohen
mailto:tzafrir@technion.ac.il
http://www.technion.ac.il/~tzafrir
-- Attached file included as plaintext by Listar --
-- File: hello.pl
#!/usr/bin/perl
print "hello, world\n"
=================================================================
To unsubscribe, send mail to linux-il-request@linux.org.il with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail linux-il-request@linux.org.il