On Thu, Sep 13, 2001 at 01:08:21PM -0600, Phil Wood wrote:
> So, there are at least two things wrong here. The obvious, is that the
> code needs to be patched so that length goes to zero in our life time,
The current code in CVS does a separate check for a zero-length
attribute.
> and the other is more checks need to be done to insure that in fact one is
> really looking at a radius packet. A hint, to help with the later problem
> is that the destination port is 111.
That's a problem that Ethereal has as well - if you have a packet that
happens to come from a "registered" port (i.e., one your analyzer
recognizes) and that also goes to a "registered" port, if you pick the
wrong port you mis-dissect the packet.
Unfortunately, there isn't a general solution. Sanity checks on the
packet could help, although too stringent sanity checks mean that if
you're analyzing a network problem and the problem is that some protocol
implementation is putting malformed packets onto the wire, it can be
harder to diagnose, as the packet will not be treated by your analyzer
software as being for the packet in question.
Ethereal lets you disable protocol analyzers; that might be one way of
handling the problem.
> Another assist could come from judicious placement of checks for service
> ports in tcp and upd printers (print-tcp.c, and print-udp.c). If, one were
> to look for the low service port numbers, before the ones greater than 1023,
> then this problem with mis-interpretation of radius would only come into
> play when both source and destination ports are greater than 1023, or
> if the port less than 1024 had no "printer", or someone has purposely
> composed a packet to break tcpdump.
I've been thinking of doing something such as that for Ethereal, i.e.
instead of first checking the source port and then checking the
destination port (or vice versa), first check the lower of the two ports
and then check the higher of them.
That also doesn't always fix the problem, although it might make it less
likely to happen.
> I'm wondering if the various printers for services such as radius and smb should
> be grouped into the "known types" of services, under the 'T' umbrella.
"T" umbrella in what sense? In the sense of something you use the "-T"
flag for? Unfortunately, that requires you to specify a filter
expression, but SMB, at least, is almost always if not always going to
be on UDP port 138 and either TCP port 139 or 445 (and the NetBIOS Name
Service is almost always if not always going to be on UDP port 137).
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
