Onderwerp: ZA Security Hole

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 write to ZA Labs too, but no answer.


Greets, Damjan

_____________ NOD32 Information _____________

This message was checked by NOD32 antivirus system.
http://www.nod32.com
__________________________________________

Damjan, I have just tested it in Zone Alarm Pro 4.5.538.001 and it
worked exactly as you said it would, its vulnerable . hope they patch
it soon... greets


--
Pablo G. Sabbatella <pgs@kerozene.com.ar>
http://www.kerozene.com.ar/

------------- Reply separator ----------------

Wednesday, April 14, 2004, 5:44:50 PM, usted escribió:

DK> Hello!

DK> I think, I discover some kind of security hole in ZoneAlaram - any version.
DK> The problem is hidding in E-mail Protection. Because I'm form Slovenia (not
DK> Slovakia), our alphabet does have some letters with roof (c - è, s - ¹, z -
DK> ¾). And when the name of e-mail attachment contain any of these three
DK> letters, it don't go to the qurarantine (if the attachment do have right
DK> extension of course). I think that can be security threat. From this reason
DK> I write to you. If this is mistake, I'm sorry to steal your time with this
DK> e-mail. And sorry for my bad english

DK> I write to ZA Labs too, but no answer.


DK> Greets, Damjan

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).
>
> Greets, Damjan


I played around a bit to find out whether my own computer (with
ZoneAlarm Pro) was vulnerable and, accidentally, found a similar
behaviour from my ISPs mailserver, apparently being Exim 4.24.

When attaching any 'normally' named .EXE, my email is returned to me by
Exim, with a note saying: "This kind of attachment is not good for
you.....".
If I rename the same .EXE to, say, (c).exe, it gets delivered and
ZoneAlarm lets it in without quarantining it.

Two bugs for the price of one!


cheers
Samps

On Wed, 14 Apr 2004, Damjan Kreft wrote:

> I think, I discover some kind of security hole in ZoneAlaram - any versio=
n.
> The problem is hidding in E-mail Protection. Because I'm form Slovenia (n=
ot
> Slovakia), our alphabet does have some letters with roof (c - ?, s - =A8,=
z -
> =B8). 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 reas=
on
> I write to you. If this is mistake, I'm sorry to steal your time with thi=
s
> e-mail. And sorry for my bad english
>
> I write to ZA Labs too, but no answer.

Are these attachments passed through regardless of filter conditions? Or
are they blocked/stripped now?

Hugo.

--=20
All email sent to me is bound to the rules described on my homepage.
hvdkooij@vanderkooij.org=09=09http://hvdkooij.xs4all.nl/
=09 Don't meddle in the affairs of sysadmins,
=09 for they are subtle and quick to anger.

On Wed, 2004-04-14 at 21:44, Damjan Kreft wrote:
> Hello!
> =

> I think, I discover some kind of security hole in ZoneAlaram - any versio=
n.
> The problem is hidding in E-mail Protection. Because I'm form Slovenia (n=
ot
> Slovakia), our alphabet does have some letters with roof (c - =E8, s - =
=B9, z -
> =BE). 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 reas=
on
> I write to you. If this is mistake, I'm sorry to steal your time with thi=
s
> 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 i=
t.
However, non-conforming software WILL decode the word, find the trailing .e=
xe
and then assume that the attachment is executable.

This is a real dilemma for any software which has the intention of preventi=
ng
unsafe content from reaching the user. It is only necessary because the mai=
n
software the user is using is itself unsafe and insecure. But the protectin=
g
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, th=
en
that is a real problem for the writers of the protecting software. They hav=
e
to know the whole behaviour of the unsafe software.

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

So, check the 'raw' message and look at how the filename appears in the MIM=
E
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@isode.com>
Isode Limited

Hello,

I couldn't reproduce the errors, neither with braces () nor with unicode
characters -- all files where renamed (quarantined) even if they had some
problems with the correct display of the filename.

I tested this with a current Zone Alarm Pro (downloaded today, April
21st) and a Windows XP Pro SP1 and all Patches.

Any further information about the problem would be helpful.

cheers,
--
Patrick Brauch <pab@heisec.de>
heise security http://www.heisec.de
c't Magazin fuer Computertechnik http://www.heise.de/ct
PGP-Fingerprint: E7F9 7F94 AE61 135C 3380 6248 1110 0CAD 3263 ED8D