FW: Vulnerabilities in Norton Antivirus for Exchange

[mgiordano () SYMANTEC COM (Mike Giordano)]

Hello there,

Your below e-mail was sent to me from one of my customers as they were
concerned with how Symantec was going to address the issues you pointed out
with our Norton AntiVirus for Exchange product.

Per my Systems Engineer:
"We have Fixed both the issues listed, the Fail-Open issue that he is
describing was fixed with the 2.01 code and the second one dealing with the
LFN zip files was fixed by SARC in a scan engine update."

I thought you might find this info useful.

Michael Giordano
Symantec Corporation
Educational Account Representative
115 Murray Drive
Allentown, PA 18104
(610)530-8300
(610)530-8989 Fax
MGiordano () Symantec com

---------------------- Forwarded by Mike Giordano/Cupertino/Cal/SYMANTEC on
06/21/2000 08:33 AM ---------------------------

"Malm, Loren D." <LMALM () bsu edu> on 06/16/2000 06:58:44 AM

To:   Mike Giordano/Cupertino/Cal/SYMANTEC@SYMANTEC
cc:   "'jbechtol () bellind com'" <jbechtol () bellind com>
Subject:  FW: Vulnerabilities in Norton Antivirus for Exchange

Mike,

We are anxiously awaiting the quotes I discussed with you in my earlier
e-mail message, please see that one for details.  Additionally, I would
be interested to learn when these problems aer going to be addressed.
We have seen this behavior as well.

Loren

-----Original Message-----
Date:   06/14/2000  09:02 pm -0500  (Wednesday)
From:  Jim Rosenberg <jr () AMANUE COM>
To:  <BUGTRAQ () SECURITYFOCUS COM>
Subject:  Vulnerabilities in Norton Antivirus for Exchange

Norton Antivirus for Exchange (NavExchange), a product of Symantec,
suffers
from two major problems, with impact described below.  The system tested
was
version 1.5.  The most recent version is 2.0, which I have not had the
opportunity to test, but based on information from Symantec I believe
2.0 is
also vulnerable to the same problems.

These problems were reported to Symantec on 5/22/00, acknowledged as
received on 5/23/00.  Symantec's only response so far is to say that the
issues have been "forwarded to QC".  They have not given me as a
customer
any indication that a fix is available, or that they understand the
urgency
of the problem.

The issues below were reported to CERT on 6/6/00.

1.  "Fail-Open" Design

When an inbound e-mail message arrives, a separate service (NavExchange)
is
contacted to scan messages for viruses.  Under certain circumstances --
not
entirely clear -- NavExchange will enter a state in which it fails to
properly respond.  When it enters this state, messages containing
viruses
will be transmitted through to the addressed recipent(s), leaving the
system
completely unprotected.  I have at least one fairly clear case in which
it
apparently entered this state as the result of the LiveUpdate process.
In
other cases I suspect it can enter this state as the result of errors in
the
scanning process, e.g. 2. below.

When NavExchange has entered this "fail-open" state, an incoming e-mail
message containing a virus will leave an error message in the Event Log.
Thus the NavExchange system is not completely "dead", and even seems
somehow
aware of its own failure.  It is not clear that Symantec has warned
customers of the urgency of acting on these Event Log messages, or that
they
are completely unprotected when this happens.

An example of such a message (as exported by the NT Resource Kit utility
DUMPEL) looks like this:

6/6/2000 4:07:42 AM 1 400 45 NavExchange N/A MAIL 80004005h Jim
Rosenberg\Inbox Automated Virus Check Message eicar_eicar.com

By contrast, a "normal" virus detection Event Log message looks like
this:

6/6/2000 5:53:17 AM 2 384 3 NavExchange N/A MAIL EICAR Test String.68
eicar_eicar.com Jim Rosenberg\Inbox Repaired

When NavExchange has entered this "fail-open" state it will apparently
stay
in this state indefinitely until the service is stopped and restarted.
Once
the service has been restarted, it appears virus protection is restored.

2.  Buffer Overrun in the NavExchange unzip engine

Because an e-mail message could contain an attachment which is a .zip
file,
and members of the .zip archive might contain viruses, NavExchange
includes
a component for unzipping files.  This component contains a buffer
overrun
when the .zip attachment contains long file names.

On 5/15/00, a message was posted to Bugtraq publishing a vulnerability
in
Eudora concerning .zip attachments with long file names.  An attachment
was
included to illustrate the problem.  This attachment caused a
NavExchange
failure, indicating that NavExchange suffers from the same problem.

The message in question has Message-ID
<002801bfbe6c$eccd5bd0$0100a8c0@ultor> from Ultor <Ultor () HERT ORG>,
subject:

Eudora Pro & Outlook Overflow - too long filenames again

By sending this message through my mail system I can, with 100%
reproduceability, cause NavExchange to fail.  The vendor has
acknowledged
that this attachment "will take down our decomposers".

Impacts fall into three grades of severity:

A) Entry Mechanism for viruses

A virus "armored" inside of a .zip attachment with long file names is
virtually guaranteed to be able to slip through NavExchange and reach
the
recipient.  In this case the system administrator will have an Event Log
message noting the failure, but may not realize the implications.  Many
NT
systems have no method of explicitly notifying the system administrator
when
Event Log messages of a particular kind occur, and indeed the whole
Event
Log mechanism typically requires dilligence on the part of the system
administrator to scan these logs manually.  Since such an armored e-mail
message could arrive overnight or on a weekend, there is more than
sufficent
time for the message to trigger an infection before the Event Log
message is
noticed.

B) A remote user may be able to disable virus protection

I suspect but cannot prove that mechanism 2) above may be able to induce
the
fail-open state 1) described above.  I cannot actually cause this to
happen.
I do know that subsequent to receiving the Bugtraq message described
above,
my system was in the fail-open state and was unprotected for several
days.

C) A remote user may be able to compromise the security of the mail
server

Because problem 2) above is a buffer overrun, there is the potential
that a
suitably designed exploit could execute code as the Exchange user.  I
should
emphasize that I *don't know* if this buffer overrun is exploitable, but
I
suspect it is.  Such an exploit could at a minimum compromise any files
or
registry keys to which the Exchange user has rights, and in the worst
case
(if the Exchange user runs as Administrator) the entire mail server.

(See attached file: Mime.822)

<HR NOSHADE>
<UL>
<LI>application/octet-stream attachment: Mime.822
</UL>