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

RE: mail trojans in linux



well, i will never argue with ones opinion. but i wish to contest the claim that because i know a shell that
does not do that or i should seperate this and that. why should a programmer do that? what if he don't know
about it? no one teach u that at engineering school right?
so what is the solution? use security measures like mail Filters sandboxes and standards. only those can protect the users from unexpected results from the variety of programs.
And i wish to turn your attention to the microsoft problem, where many viruses, trojans, backdoors, exploits exists not Only because the sources are closed, but because they are often not complying to standards and no one enforce them on microsoft. I hope that the new government will do what it promised recently and enforce this conditions on them.

* - * - *
Tzahi Fadida
Tzahi@mailandnews.com
Fax (+1 Outside the US) 240-597-3213
* - * - * - * - * - *


-----Original Message-----
From: Tzafrir Cohen [mailto:tzafrir@technion.ac.il]
Sent: Sunday, September 09, 2001 3:14 PM
To: Tzahi Fadida
Cc: Linux-IL mailing list
Subject: 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