UGN Security Forums
My ProfileMember DirectoryLogin
Search our ForumsView our FAQView our Site Rules
View our CalendarView our Active TopicsGo to our Main Page

UGN Security Store
 

Network Sites UGN Security, The GoNix Initiative, Elite Web Gamers, Back of the Web, EveryDay Helper, VNC Web Design & Development
September
Su M Tu W Th F Sa
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30
Sponsored Links
Latest Postings
The History Thread...
by Gremelin
Yesterday at 09:42 AM
Doom 3
by Cyrez
09/11/14 08:58 PM
Amazon Gift Card Generator/KeyGen?te
by Gecko666
08/22/14 09:21 AM
Latest Reviews
Topic Options
Rate This Topic
#40043 - 05/14/04 07:59 PM "Extremely critical" problems found in Symantec firewalls
Phatal Offline
UGN News Staff

Registered: 04/05/04
Posts: 298
Loc: Houston, TX
A SECUNIA BULLETIN warns of a number of "extremely critical" holes in Symantec firewalls which could lead to denial of service attacks and system access.
Secunia said eEye reported multiple vulnerabilities in Symantec products including Norton Internet Security 2003/2002, AntiSpam 2004, Symantec Client FIrewall and Personal Firewall, and Symantec Client Security.

These could let a hacker into your system or compromise a vulnerable system, Secunia says.

However, there are patches available through the LiveUpdate feature and technical support channels, says Secunia.

Its advisory is here:: http://secunia.com/advisories/11066/

You can view the original article here...
http://www.snpx.com/cgi-bin/news5.cgi?target=.../cgi/NGoto/58636299?-2622

Top
Sponsored Links
      
#40044 - 05/17/04 08:42 PM Re: "Extremely critical" problems found in Symantec firewalls
Phatal Offline
UGN News Staff

Registered: 04/05/04
Posts: 298
Loc: Houston, TX
The SYMDNS.SYS driver included in the Symantec firewall product line 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.

Top
#40045 - 05/17/04 08:44 PM Re: "Extremely critical" problems found in Symantec firewalls
Phatal Offline
UGN News Staff

Registered: 04/05/04
Posts: 298
Loc: Houston, TX
You can read the rest of these advisories here...

http://eeye.com/html/Research/Advisories/index.html

Top

Featured Member
Registered: 08/22/14
Posts: 1
Forum Stats
2148 Members
46 Forums
34470 Topics
69640 Posts

Max Online: 1567 @ 04/25/10 02:20 AM
Top Posters
UGN Security 27632
Gremelin 7193
§intå× 3255
SilentRage 1273
Ice 1146
pergesu 1136
Infinite 1041
jonconley 955
Girlie 908
unreal 860
Newest Members
Tim050, Gecko666, defghi795767, Devo60, ali
2148 Registered Users
Who's Online
1 registered (Gremelin), 305 Guests and 359 Spiders online.
Key: Admin, Global Mod, Mod
Latest News


Donate
  Get Firefox!
Get FireFox!