Re: Vulnerabilities in Norton Antivirus for Exchange

[mprosser () SYMANTEC COM (Prosser, Mike)]

Jim,
I prodded the NAVMSE product team on this issue a bit.  They have been
working hard reproducing the problems and coding fixes.  Apologize for the
delayed response.

Mike Prosser
Research Manager
Enterprise Solutions Division
Symantec Corp.

"NAV 2.1 for Microsoft Exchange

We believe that both of the issues listed below are fixed in NAVMSE 2.1.  It
was difficult to reproduce the issue on "Fail-Open" so we are doing
additional code walk throughs as a precaution.
The actual scanning is now handled by separate processes that can be
monitored for problems.  They can be shutdown and restarted when a problem
occurs.  Files that cause scan problems are considered suspect and are moved
to the quarantine."

> -----Original Message-----
> From: Jim Rosenberg [mailto:jr () AMANUE COM]
> Sent: Wednesday, June 14, 2000 4:02 PM
> 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.