More and more, these sorts of occurrences seem to indicate something
like a script language to define protocols, and a simple script
parser.
-Ashok
Gilbert Ramirez writes:
> On Fri, Dec 03, 1999 at 04:20:52PM -0600, Guy Harris wrote:
> >
> >
> > > I've been using Ethereal today specifically to debug strange NFS problem
> > > at work. I thought there might be some VFS bug in the Linux kernel, but
> > it
> > > didn't even dawn on my to consider malformed packets!
> >
> > Cf. my earlier comment, in another mail thread, on how one reason for
> > using Ethereal is to check for packets that *aren't* following the rules
> > of their protocol, and hence the requirement that Ethereal not assume
> > all packets are valid....
>
> Absolutely. In a similar vein, I think it's time to decide on a procedure
> for guarding against having a protocol dissector read beyond the captured
> data, either because of a short packet or because of bad data in the
> packet telling the dissector to keep on reading. I'd like to document
> this procedure and put it in our fledgling doc/ directory, so that all
> of the protocol dissectors solve this nasty problem in the same way.
>
> Here's a couple things off the top of my head. Some of these
> may be too harsh.. should we try to decode partial packets, retrieving
> as many fields as possible? This would mean lots of BYTES_ARE_IN_FRAME()
> checks, or a setjmp()/longjmp() solution that Guy once mentioned to me.
>
> 1. If the length of your protocol header is a constant size, check to
> see if there is enough data. If so, decode. If not, stop dissection
> (e.g., Ethernet)
>
> 2. If the length of your protocol header is embedded in the header, you
> should check to see if that data offset is available, get the data if it is,
> then compare the amount of data with the retrieved size of header/packet.
> If you have the entire packet decode it, if not, stop dissection.
> (e.g., token-ring (the source-route flag and RCF combined tell us
> how many bytes we have))
>
> 3. If the length of your protocol header is not embedded in the header,
> but you have multiple sections in your header, each of which has either
> a constant size or an embedded length, loop on each section, checking
> the amount of data in each iteration of the loop
> (BOOTP, SNA)
>
> I'm sure my own protocol dissectors, especially the older ones (BOOTP!)
> don't follow the outlined procedures. :)
>
> These are hasty thoughts on my part; what are other situations, and
> perhaps other solutions?
>
> --gilbert
>
--
--- Asok the Intern ----------------------------------------
IOS Network Protocols, Cisco Systems
250 Apollo Drive, Chelmsford, MA 01824
Ph: 978-244-8387
