ZA Security Hole

[Damjan Kreft]

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
__________________________________________

[Pablo G. Sabbatella]

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

[Samps]

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

[Hugo van der Kooij]

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.

[David Wilson]

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

[Patrick Brauch]

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