Message-ID: <1082447527.7603.799.camel@alpha.isode.net>
Date: Tue, 20 Apr 2004 08:52:07 +0100
From: David Wilson <David.Wilson@...de.com>
To: Damjan Kreft <damjan.kreft@...l.net>
Cc: bugtraq@...urityfocus.com
Subject: Re: ZA Security Hole


On Wed, 2004-04-14 at 21:44, Damjan Kreft wrote:
> Hello!
> 
> I think, I discover some kind of security hole in ZoneAlaram - any version.
> The problem is hidding in E-mail Protection. Because I'm form Slovenia (not
> Slovakia), our alphabet does have some letters with roof (c - č, s - š, z -
> ž). And when the name of e-mail attachment contain any of these three
> letters, it don't go to the qurarantine (if the attachment do have right
> extension of course). I think that can be security threat. From this reason
> I write to you. If this is mistake, I'm sorry to steal your time with this
> e-mail. And sorry for my bad english :)

I do not know the ZoneAlarm product, but I presume you are attempt to
use a feature which blocks Email attachments which have an associated
filename which ends in .exe (or whatever).

I think there might be two possible explanations:

1) There is a bug in ZoneAlarm. This is suggested by the correspondent
who reported a problem with a filename containing '()'. This does not
require any special encoding (although a stupid UA might use the method
I outline below when it is not needed).

2) ZoneAlarm is not bug-for-bug compatible with certain mail user agents
which are in specific violation of the Internet standards.

The associated filename appears in the (non-standard) name parameter to
the Content-type, or the standard filename parameter to the
Content-disposition field. In common with all MIME headers, it cannot
contain characters other than US-ASCII. So, how do you get a filename
with non-ASCII? There is a standard for this: RFC 2231 (published in
November 1997, so there has been a long time for software writers to
adopt this).

However, some software I have seen ignores this standard. Instead, these
use MIME 'encoded words' (RFC 2047). These are intended for use in
standard RFC 2822 headers to include non-ASCII, but can only be used in
specific locations, such as the subject field, and the "name" part of
addresses. The RFC contains this specific prohibition:

   + An 'encoded-word' MUST NOT be used in parameter of a MIME
     Content-Type or Content-Disposition field, or in any structured
     field body except within a 'comment' or 'phrase'.

The value part of a parameter is not syntactically a 'phrase', so this
prohibition is unambiguous.

So, software which conforms to standards should not be expecting an
encoded-word within a MIME parameter, so it will not attempt to interpret it.
However, non-conforming software WILL decode the word, find the trailing .exe
and then assume that the attachment is executable.

This is a real dilemma for any software which has the intention of preventing
unsafe content from reaching the user. It is only necessary because the main
software the user is using is itself unsafe and insecure. But the protecting
software has to know how the unsafe software is going to treat any possible
input. If the unsafe software is not standards conforming, but more lax, then
that is a real problem for the writers of the protecting software. They have
to know the whole behaviour of the unsafe software.

Another example of this is the lax treatment of text/plain. The MIME type and
sub-type should be the first items used to determine the treatment of a MIME
body. However, some systems ignore this, and if it contains HTML, for instance,
render the HTML. Even worse, some systems could treat the text/plain as executable.

So, check the 'raw' message and look at how the filename appears in the MIME
headers for the attachment. If it is an encoded-word, the problem is
standards-violating software, but ZoneAlarm does not allow for this.

-- 
David Wilson <David.Wilson@...de.com>
Isode Limited

Powered by blists - more mailing lists