[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: mail trojans in linux



On Sun, 9 Sep 2001, Tzahi Fadida wrote:

> On Sunday, September 09, 2001 12:55 PM, Tzafrir Cohen wrote:
> > 
> > On Sun, 9 Sep 2001, Ely Levy wrote:
> > 
> > > sure download a vbs interperter for linux and use the magic key option of
> > > the kernel to execute it.
> > > 
> > > then you'll have your own opensource linux mail torjan;)
> > 
> > I don't need no VBS script for that: bourne shell is good enough...
> > 
> > It's really no big deal to write a small perl/bash/whatever script that,
> > upon execution opens big holes in the system (depending on the priviliges
> > on the user executing the script, and on the circumstances).
> > 
> > The issue with VBS scripts is that mail clients easily execute scripts
> > from messages they recieve. I hope no mail client in the linux areana will
> > be as stupidly-designed as that, now that this lesson has been learned the
> > hard way by outlook and alike (if it ever needed learning).
> > 
> > (And the same mail clients easily execulte any other windows executable:
> > PE and other binarie can cause the same ammount of damage)
> I don't think that stupid is relevant here in relation to the client
> side.

> I think stupid does apply when u run user applications on root accounts
> or with root setuid.
> Fact is - linux warns u not to run root apps when u load X.
> who cares if one user data is got erased, when the other users don't.

I, as a user, wouldn't like to see my documents erased (or mailed
elsewhere).

But there are a couple of things of concern to the sysadmin:

* it is generally quite easy for a user to consume much of the network
resources of a box

* A user can consume other resources (cpu, memory, isk space), if not not
limited by the sysadmin. Any such limitation also puts some burden on the
user, and may not be welcomed in certain situations.

* such a script can open a hole for an attacker to execute arbitrary
commands with the user's priviliges (not necessarily through an open port.
There are other ways). This lets the attacker either an easier base to try
to detect local root exploits, or simply as another base of operations.

> However, i think that a preventive approach should be considered if
> there are important materials in
> a particular user directory which are not periodically backuped. 

Think about it this way: do you insure your house against theft _instated_
of locking the doors?

> you
> could, in essense run some email checker for your users before they get
> it into their clients because no matter what u'll do, your users will
> always fall for Social Engineering atacks.

I wish not to make those social attacks _so_ easy.

Why should a user need to execute such an executable in the first place?

On wiindows executables are used as a standard archive format, as a way to
transfer shockwave animations, etc. But those tasks don't really require
an executable. It is simply because the user interface of windows made it
easy to transfer data together with the "viewer" (instead of a proper
seperation between documents and code.

When I run shoscscript (-dSAFER) I can be sure that it won't execute some
hidden script. When I run xli (with the buffer overflow eliminated) to
view a file, I know that it will either show me an image, or not. But will
never try to "execute" that document. I know tha my pine (that uses
mailcap) never 'opens' a document. It always 'views' the document. And I
like it this way. If I need to modify that document, then I should first
'file' it in my local documents (Save as...) .

I don't think that there is a noticable loss of usability. But there is a
gain in security.

-- 
Tzafrir Cohen
mailto:tzafrir@technion.ac.il
http://www.technion.ac.il/~tzafrir



=================================================================
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