http://www.eeye.com/html/Research/Advisories/AD20040512A.html
http://www.eeye.com/html/Research/Advisories/AD20040512B.html
http://www.eeye.com/html/Research/Advisories/AD20040512C.html
http://www.eeye.com/html/Research/Advisories/AD20040512D.html

----

Symantec Multiple Firewall NBNS Response Processing Stack Overflow

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 vulnerability in Symantec's Norton 
Internet Security products that would allow a remote, anonymous attacker to execute 
arbitrary code on a system running an affected version of the product. By sending a single 
specially-crafted NetBIOS Name Service (UDP port 137) packet to a vulnerable host, an 
attacker could cause an arbitrary memory location to be overwritten with data he or she 
controls, leading to the execution of attacker-supplied code with kernel privileges and 
the absolute compromise of the target.

The vulnerability exists due to a flaw in the way Norton Internet Security processes 
incoming UDP packets with a source port of 137 (NetBIOS Name Service). If such a packet is 
received, it is validated as a proper NBNS packet and certain information from the packet 
is stored. A specifically crafted packet can cause the code that copies information out of 
the packet to instead write packet data to an arbitrary memory location, a flaw that can 
be leveraged in order to malicious execute on an affected system. In order for this 
vulnerability to be exploitable, the Norton Internet Security firewall must be configured 
to allow incoming UDP/137 packets, a setting which is not present by default, but may be 
enabled by the user or network administrator in order to facilitate Windows file sharing.

Technical Description:
The SYMDNS.SYS driver included in Norton Internet Security validates DNS and NetBIOS Name 
Service responses before allowing them through the firewall. As it turns out, the handlers 
for both types of packets have grave security issues, but this advisory focuses on NBNS 
packets and leaves DNS up to Barns and Karl. The intended protocol is determined by the 
source port of the UDP packet -- 53 for DNS, 137 for NBNS -- and after verifying that the 
incoming packet is marked as a response according to the header, it is passed off to the 
appropriate analysis routine, both of which perform similar but protocol-specific 
processing on the answer data contained therein (although no further validation takes place).

In the case of the NBNS routine, the questions in the packet are skipped, and the answers 
are only examined if they have Class 01h (INET) and Type 01h (A) or 20h (NB). For answers 
meeting these criteria, the name is first-level decoded, the IP addresses are stored in a 
list, and both are later recorded internally in a global array. (As a refresher: first 
level encoding represents each byte of a name as two letters from 'A' to 'P', which 
correspond to the high and low hexadecimal digits of the byte's value -- 'A' is 0, 'B' is 
1, 'C' is 2, and so on. For example, "eEye" is represented in hexadecimal as 65h 45h 79h 
65h, and is therefore encoded as "GFEFHJGF". See RFC 1001, Section 14.1, for more 
information.)

The first of many problems that make this vulnerability possible is that the first-level 
decoding routine will decode an amount of data corresponding to the length byte preceding 
the encoded name, making it possible to store up to 127 arbitrary bytes (plus a null 
terminator) into a 32-byte stack buffer provided by the main NBNS processing routine. 
Although this condition is insufficient to overwrite the return address directly (the 
buffer begins at EBP-118h, but only an 80h-byte write is possible), there is an index 
variable that can be overwritten in order to manipulate the IP address copying loop later 
in the function. The NBNS processing routine's stack frame can be represented as follows:

PBYTE var_11C;
char var_118[0x20];
DWORD var_F8;
DWORD var_F4;
DWORD var_F0;
PBYTE var_EC;
DWORD var_E8[0x18];
char var_88[0x80];
PBYTE var_8;
PBYTE var_4;
(saved EBP at EBP+0)
(saved EIP at EBP+4)
...

var_118 is the destination buffer passed to the first-level decode routine, and just about 
everything after it is initialized after the decoding overwrite occurs, or is otherwise 
useless: var_E8/var_88 is memset to 0; var_EC and var_F0 get wiped out; var_F4 is just an 
outer loop counter (infinite loop: DoS); and var_8 and var_4 aren't even reachable. The 
exception here is var_F8, which is initialized to 0 at the beginning of the function, used 
to index into a stack array (var_E8), and is not checked for any out-of-bounds values 
other than the exact size of the array in elements (18h). The fact that the variable is 
located immediately after the overflowable buffer just adds to the convenience.

Once the answer name has been decoded, the NBNS processing routine enters another loop to 
copy IP addresses from the response into var_E8. Since the contents of the list are 
supposed to be accumulated from across all answers in the packet, var_F8 is not 
reinitialized when the loop begins, and furthermore, the terminating condition of the loop 
is only that var_F8 equals 18h (no greater-than). As a result, once the variable has been 
overwritten with a sufficiently high value, "IP addresses" within the packet will be 
written onto the stack at [EBP-E8h+(var_F8*4)] until the answer's data length has been 
exhausted (up to roughly 64KB).

Because the length of the first-level encoded name must be at least 40h in order to touch 
var_F8, the routine that skips a length-prefixed name component will mistake the length 
byte for a compressed name pointer, and will only advance by two bytes instead of (length 
of name + 1). This means the data that normally follows the encoded name actually begins 
"inside" the name, but this doesn't matter because the first-level decoding routine does 
not validate that the name consists only of characters from 'A' to 'P'. Additionally, it 
does not check for compressed name pointers and will happily accept any value for the 
length byte. The result of this stack buffer overflow / consistent lack of validation 
combo is another UDP remote kernel vulnerability.

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.

Credit:
Discovery: Derek Soeder

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

Greetings:
damodadudewn; CMC, BG, Jenna, Lan, BP, JKP, Daryl, RLS, KT, NV; Brett Moore; Riley; and 
Colleen R. (thanks anyways for the offers!)

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

----

Symantec Multiple Firewall DNS Response Denial-of-Service

Release Date:
May 12, 2004

Date Reported:
April 19, 2004

Severity:
High (Remote Denial of Service)

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 second vulnerability in Symantec's Norton Internet 
Security products that can be remotely exploited to cause a severe denial-of-service 
condition on systems running a default installation of an affected version of the product. 
By sending a single malicious DNS (UDP port 53) response packet to a vulnerable host, an 
attacker can cause the Symantec DNS response validation code to enter an infinite loop 
within the kernel, amounting to a system freeze that requires the machine to be physically 
rebooted in order to restore operation.

Technical Description:
The SYMDNS.SYS driver included in Norton Internet Security validates each DNS response 
packet before allowing it through the firewall, attempting to reassemble a DNS answer name 
into a single dotted string as part of this process. Although not as hot as Barns's and 
Karl's stack overflow in the same routine, there is also a denial-of-service vulnerability 
in the name component concatention code involving the processing of compressed name 
pointers (name component with a length byte >= 40h, as far as SYMDNS is concerned, 
followed by the offset of the name component to substitute in place of the pointer). 
Specifically, if a compressed name pointer is constructed that points to itself, this 
routine will loop infinitely as it forever follows the compressed name pointer, to the 
compressed name pointer, to the compressed name pointer...

The following is a DNS response packet containing such a pointer:

Offset Size Data Description
------- ------- --------------- --------------------------------
0000h WORD xx xx Transaction ID
0002h WORD 80 00 Flags (bit 15: response)
0004h WORD 00 01 Number of questions
0006h WORD 00 01 Number of answer RRs
0008h WORD xx xx Number of authority RRs
000Ah WORD xx xx Number of additional RRs
000Ch WORD C0 0C Compressed name pointer to itself

By sending an attack packet to any open UDP port on a vulnerable system, from a source 
port of 53, the vulnerable code will be reached and the denial-of-service condition will 
occur.

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.

Credit:
Discovery: Barnaby Jack, Karl Lynn, Derek Soeder

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

Greetings:
D12/2, Ink, AiC, and we would also like to thank our contact Mike over at Symantec for 
being patient and cooperative throughout the reporting process.

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

----

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.

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

----

Symantec Multiple Firewall Remote DNS KERNEL Overflow

Release Date:
May 12, 2004

Date Reported:
April 19, 2004

Severity:
High (Remote Kernel Access)

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. A buffer overflow exists within a core driver component that 
handles the processing of DNS (Domain Name Service) requests and responses. By sending a 
DNS Resource Record with an overly long canonical name, a traditional stack-based buffer 
overflow is triggered. 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.

It should also be noted, that due to a separate design flaw in the firewalls handling of 
incoming packets, this attack can be successfully performed with all ports filtered, and 
all intrusion rules set.

Technical Description:
This specific vulnerability exists within the SYMDNS.SYS driver. The stack overflow arises 
due to an implementation flaw in the routine that processes the CNAME field of incoming 
Resource Records. A canonical name field is represented as a series of labels, and is 
terminated by a label with a zero byte length. Each string consists of a one byte length 
specifier, followed by that number of characters. A typical canonical name field would be 
of the following format:

0x03 // length
www // string component
0x04 // length
eEye // string component
0x03 // length
com // string component

Each time the SYMDNS.SYS driver encounters a length field, the field is then used as a 
counter to copy the bytes that follow. These bytes are copied directly into a stack based 
buffer. Due to poor sanity checking on the total CNAME field, the routine will accept a 
large number of length specifiers and byte sequences. As the routine loops through each 
field, the bytes are concatenated, and an exploitable condition in the KERNEL is reached.

A separate design flaw allows this attack to succeed with the firewall running at it's 
most locked-down state. The firewall will happily accept any packet that has a source port 
of 53, regardless of port filtering.

The fact that this vulnerability is exploitable over UDP adds another serious layer to an 
already critical flaw.

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.

Credit:
Discovery: Barnaby Jack and Karl Lynn

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

Greetings:
R Hassell (aka Gilligan), the NZ crew, Gary Golomb, Rich Walchuck, Jason Dameron, Sam 
Stover, Matt Dickerson, and Kelly H.

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