Vulnerabilities in Norton Antivirus for Exchange

[jr () AMANUE COM (Jim Rosenberg)]

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.