[Full-Disclosure] EEYE: Symantec Multiple Firewall NBNS Response Remote Heap Corruption

• Previous message: Marc Maiffret: "[Full-Disclosure] EEYE: Symantec Multiple Firewall NBNS Response Processing Stack Overflow"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: <full-disclosure@lists.netsys.com>
Date: Wed, 12 May 2004 17:02:46 -0700

Symantec Multiple Firewall NBNS Response Remote Heap Corruption

Release Date:
May 12, 2004

Date Reported:
April 19, 2004

Severity:
High (Remote Kernel Code Execution)

Vendor:
Symantec

Systems Affected:
Symantec Norton Internet Security 2002
Symantec Norton Internet Security 2003
Symantec Norton Internet Security 2004
Symantec Norton Internet Security Professional 2002
Symantec Norton Internet Security Professional 2003
Symantec Norton Internet Security Professional 2004
Symantec Norton Personal Firewall 2002
Symantec Norton Personal Firewall 2003
Symantec Norton Personal Firewall 2004
Symantec Client Firewall 5.01, 5.1.1
Symantec Client Security 1.0, 1.1, 2.0(SCF 7.1)
Symantec Norton AntiSpam 2004

Description:
eEye Digital Security has discovered a critical remote vulnerability
within the Symantec firewall product line. There is a remote heap
corruption vulnerability in SYMDNS.SYS, a driver that validates NetBIOS
Name Service responses, which can lead to execution of arbitrary code
for various Symantec products. Successful exploitation of this flaw
yields remote kernel access to the system.

With the ability to freely execute code at the Ring 0 privilege level,
there are literally no boundaries for an attacker.

Technical Description:
This specific vulnerability exists within the SYMDNS.SYS driver. The
code in SYMDNS.SYS that validates NetBIOS Name Service responses (source
port UDP/137) does not perform proper bounds checking when reading
answer data from the packet. Because the byte order of each answer
resource record's type, class, time-to-live, and data length are
switched in-place within a copy of the packet, it is possible to corrupt
heap memory in such a way that can lead to the execution of arbitrary
code within the kernel.

The following is a sample NetBIOS Name Service response packet:

Offset Size Data Description
------- ------- --------------- --------------------------------
0000h WORD xx xx Transaction ID
0002h WORD 80 00 Flags
0004h WORD 00 00 Number of questions
0006h WORD 00 02 Number of answer RRs
0008h WORD xx xx Number of authority RRs
000Ah WORD xx xx Number of additional RRs
000Ch BYTE 02 Length of name component
000Dh 2 CHARs xx xx First-level encoded name
000Fh BYTE 00 No more name components
0010h* WORD xx xx Answer RR: Type
0012h* WORD xx xx Answer RR: Class
0014h* DWORD xx xx xx xx Answer RR: Time-to-Live
0018h* WORD xx xx Answer RR: Data Length

If the starred (*) fields are omitted from the packet, the vulnerable
code will swap bytes in the adjacent heap block's header. SYMDNS employs
a custom heap implementation which it maintains inside of large
ExAllocatePoolWithTag-allocated blocks of kernel memory, and uses heap
block header structures of the following format:

Offset Size Description
------- ------- --------------------------------
0000h PTR pointer to next free block
0004h PTR pointer to previous free block
0008h PTR pointer to next block
000Ch PTR pointer to previous block
0010h DWORD size of data area of heap block
0014h PTR pointer to heap base address
0018h DWORD reference count (0 = free)
001Ch DWORD tag

With careful heap preparation, some specially-crafted packets, and a
modest amount of luck, it is possible to manipulate these and other heap
pointers in order to write arbitrary data to an arbitrary memory
location, which can then be leveraged in order to execute
attacker-supplied code. Because this is a kernel-mode heap-related
exploit, there will always be sitautions which will cause an
exploitation attempt to result in a blue-screen, but the odds of success
are definitely enough to qualify this as remote code execution, rather
than a remote denial-of-service.

By default, the NetBIOS Name Service is not allowed by the firewall but
is commonly used in a Windows networking environment.

Protection:
Retina Network Security Scanner has been updated to identify this
vulnerability.

Vendor Status:
Symantec has released a patch for this vulnerability. The patch is
available via the Symantec LiveUpdate service. For more information
please refer to the Symantec security advisory.
http://securityresponse.symantec.com/avcenter/security/Content/2004.05.1
2.html

Credit:
Discovery: Karl Lynn

Related Links:
Retina Network Security Scanner - Free 15 Day Trial
http://www.eeye.com/html/Products/Retina/download.html

Greetings:
Kelly H., Derek "Tex" Soeder, the guys at CORE, and Estelle L.

Copyright (c) 1998-2004 eEye Digital Security
Permission is hereby granted for the redistribution of this alert
electronically. It is not to be edited in any way without express
consent of eEye. If you wish to reprint the whole or any part of this
alert in any other medium excluding electronic medium, please email
alert@eEye.com for permission.

Disclaimer
The information within this paper may change without notice. Use of this
information constitutes acceptance for use in an AS IS condition. There
are no warranties, implied or express, with regard to this information.
In no event shall the author be liable for any direct or indirect
damages whatsoever arising out of or in connection with the use or
spread of this information. Any use of this information is at the user's
own risk.

Feedback
Please send suggestions, updates, and comments to:

eEye Digital Security
http://www.eEye.com
info@eEye.com

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

• application/ms-tnef attachment: winmail.dat

• Previous message: Marc Maiffret: "[Full-Disclosure] EEYE: Symantec Multiple Firewall NBNS Response Processing Stack Overflow"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]