Re: Hypothetical design question

["Paco Hope" <bhope () cigital com>]

On 1/27/04 10:20 PM, "Andreas Saurwein" <[EMAIL PROTECTED]> wrote:
> Its the client which OFFERS this functionality as a feature for the user.
> So, instead of needing to save the attachment to disk and executing it from
> there as you would do with any other application (and where control is
> possible), you just click on a feature provided by the email client and,
> bang, there goes your system.

I disagree. I don't think there is *more* control if you save to disk and
execute versus clicking an attachment in email. The two are exactly the
same. Clicking the attachment in the email client is basically a macro. It
saves to a temporary file, then executes the temporary file. The result is
exactly the same as if the user saved the attachment to a file and then
clicked on the file they made.  Any controls possible in one context are
possible in the other. The problem is the OS: there are very few controls
available.

We might make things safer by making it harder to do bad things within the
email client. Then the virus writers will send text in their viruses like
"be sure to save this to a file and execute it" so that their virus is
executed in a different security context. Users' inability to follow those
instructions will limit the spread of such viruses, which is really not the
line of defense we were looking for.

> An OS can never cover all functionality. Somewhere we have to draw the line.

I agree. But I think code execution controls belong in the OS, not in an
application program. If we fix the email client by putting in Magic Mojo?
that protects us from attachments, we will need the same Magic Mojo
protecting us in IE, Word, Excel, Powerpoint, etc.

> For example: where is the difference between executing an script embedded
> in an HTML mail inside an email client and executing the same script
> embedded in an HTML file on a CD?

None.  And why should there be?  Both are equally potentially hostile. From
the OS or web brower's perspective, it has no information to judge the
quality of the code. Sure email is always more suspicious than a CD. If this
CD is some hacker toolkit that your teenage son has lying around, though,
the HTML on it is just as dangerous as an email. Maybe its a script coming
from a trusted web site, but that poor site is subject to cross-site
scripting, and now the script he's executing is hostile.

> > One feature that is abused a lot by viruses is the email automation API.
>
> So what? Remove it? Knifes kill people, yet everybody can buy/use them.

No. I was just answering the question of what features get abused.  I
actually was trying to highlight how vital it is. This is a major constraint
on any solution we would try to design.

> There is always the simple excuse that the OS should do it. So far OS'es
> are not intelligent enough to protect users from stupid programmers and
> itself from stupid users.

If the OS is dumb, that doesn't mean that smart applications are possible
and/or the right solution.




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------