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
