Wireshark · Ethereal-dev: [Ethereal-dev] Is ethereal too trusting? (Was: Wrong tcp packet dissection?)

["Visser, Martin (Sydney)" <martin.visser@xxxxxx>]

Just a quick observation.

I know more then once Ethereal has been vulnerable to buffer overflow
due to malformed packets hitting a dissector, AFS issue and the SOCKS
issue discovered by George Guninski stand out.

I haven't looked at a lot of dissectors, but I was wondering how much
they "trust" the data given to them to analyse? I know it is obvious,
but a cracker won't obey netiquette, nor RFCs when it comes to attack
methods. 

I don't want to teach grandma how to suck eggs, but I guess I'm asking
all dissector maintainers to run a second check through their code to
ascertain whether they aren't too trusting of the data they receive. In
the example below, until Ronnie fixed the code, the TCP dissector
believed the IP packet somewhat, though with no bad consequence. I'm not
sure, but there may be other simple things, like a malformed packet with
a flag indicating an additional header is to follow, but that header
never arrives, and maybe we don't release the malloc'ed memory creating
a memory leak. Or we may be expecting a counter in a header to always
increment, but a malformed packet decrements it, and we look backwards
into memory no-mans-land. I'm not sure whether my paranoia is justified,
nor whether all the bounds checking needed may even be possible or
practical. Maybe we just need some guidelines for developers of
dissectors (or taps, or whatever) on what to watch for. (BTW the Perl
code I put up a few days is very lacking in validation, so I'm
definitely not pointing the finger at anyone!)

The fact that Ethereal usually runs with at least some system privileges
means we have to be extra careful. I certainly wouldn't want to see
Ethereal mentioned too many times (at least negatively) on the likes of
securityfocus.com

I think any discussion on this would be useful. 

Martin Visser ,CISSP
Network and Security Consultant 
Technology & Infrastructure - Consulting & Integration
HP Services

3 Richardson Place 
North Ryde, Sydney NSW 2113, Australia 
Phone *: +61-2-9022-1670    Mobile *: +61-411-254-513
   Fax 7: +61-2-9022-1800     E-mail * : martin.visserAThp.com



-----Original Message-----
From: Ronnie Sahlberg [mailto:ronnie_sahlberg@xxxxxxxxxxxxxx] 
Sent: Tuesday, 20 May 2003 8:37 PM
To: Yaniv Kaul; ethereal-dev
Subject: Re: [Ethereal-dev] Wrong tcp packet dissection?


I have checked in a fix to stop dissection of the packet when this
condition is detected.

Basically, the IP layer said the fragment is only 16 bytes large. Thus
you would need to enable IP layer reassembly to see the full tcp header
which is minimum 20 bytes.

The change to ethereal i implemented was to just stop dissecting the
packet in the tcp layer if the condition that either the packet
contained <20 bytes of tcp layer data or if not the full tcp header was
seen in the framgent. Also a simple text message was added to the tree
pane to indicate that someone was either broken or playing fragmentation
games. tcp packets should never be fragmented since tcp prefers to do
this itself instead of letting the ip layer do it. I guess the only
times this would happen in real life would be:
* fingerprinting by sending unusual packets (nmap which was the case
here)
* a completely broken tcp layer which allows ip fragmentation of tcp
segments
* someone playing silly buggers with the tcp header like fragment
offset:8 bytes and changing the tcp flags fields in overlapping
subsequent ip fragments to fool firewalls that are broken to not
deliberately violate rfc1812/5.2.6. I belive that all firewall product
deliberatly violates this paragraph since the alternative would be bad.



----- Original Message -----
From: "Yaniv Kaul"
Sent: Tuesday, May 20, 2003 1:25 AM
Subject: [Ethereal-dev] Wrong tcp packet dissection?


> Attached please find a single packet from an nmap scan. The packet is 
> dissected incorrectly. In particular, it seems that the next sequence 
> number is wrong, as well as the length.
> I suspect it may be due to the fact the packet's seq=0xffffffff.
>


------------------------------------------------------------------------
----
----


> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx 
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>

_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev