Folks,
I'd like to call for a general slow down in the rush to publish new
"port" analyzers. In particular, to illustrate my point, I call your
attention to the print-udp.c and it's handling of "radius (print-radius.c)".
The general tendancy seems to be towards the "Vomit" approach to
interpreting a packet. That is, with verbose set to ZERO, some "analyzers"
decide that multi-line output, or complete packet payload interpretation is
desirable. This is certainly true for print-smb.c. I think tcpdump needs
to be forced with extra verbosity (-vv for example) to dump more than just
the name of the service and possibly the services data payload (beyond the
application header). Example:
# tcpdump -n -r /tmp/radiusstuff -c 1 # but really RPC
07:05:37.860483 128.165.114.134.1646 > 128.165.114.255.111: udp RADIUS(88)
# tcpdump -v -r /tmp/radiusstuff -n -c 1
^ this is a clue that
it is NOT a RADIUS
packet.
07:05:37.860483 128.165.114.134.1646 > 128.165.114.255.111: [udp sum ok] RADIUS(88)
(ttl 64, id 41230, len 136)
# tcpdump -vv -r /tmp/radiusstuff -n -c 1
07:05:37.860483 128.165.114.134.1646 > 128.165.114.255.111: [udp sum ok] RADIUS(88)
code=59 [id 172] Attr[ [|radius?, rad_attr->len == 0] ] (ttl 64, id 41230, len 136)
^ at this point we begin to wonder if this is a radius packet.
[Note: I just patched print-radius stuff to fix bug described below, and change
the printout a bit to try some of my ideas of incremental 'v'.]
I'd go for an incremental approach, where the more "v's" the more Vomit.
Currently, print-radius does not check the value of vflag, and dumps the
entire packet. It also does not appear to check that the packet is in fact
a radius packet, but just templates the bit stream and jumps willy-nilly
into a loop, assuming it is radius. If, as in the case I managed to stumble
on, the packet is an RPC packet with a "random" source port of [1645, 1812,
1646, or 1813], the rad_attr len and type values turn out to be zero. In this
case, the radius_attr_print subroutine goes into an infinite loop, subtracting
zero from length, checking if length has gone to zero (it won't), and
printing "#%d", rad_attr->type until you either break, or in the case of
logging to a file, run out of disk space!
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, 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. If, each service had a checksum we
would be in fat city. However, as vendors, and others rush to cash in on
the Internet bonanza, good protocol design falls by the wayside. No help
there. Maybe there are some bits in the service header as well as the
length which could be used to make a decision on whether or not a service
port is real, or just a companion port number to another service such as
PORTMAPPER.
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.
The good news is that '-q' appears to cause some of the verbosity to go away.
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.
I've rambled on enough. In the short run someone might want to fix
print-radius.c at line 746 (or so) to do the following:
if ( rad_attr->len <= length && rad_attr->len > 0)
^^^^^^^^^^^^^^^^^^^^ add this test.
Thanks for your time,
Phil Wood
-
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
