A cohort o' mine asked me this question recently, and as I know that
ethereal and tcpdump both rely on libpcap, I thought perhaps someone here
might know the answer to his question.
--J
> -----Original Message-----
> From: Shelton, Raymond A.
> Sent: Monday, March 26, 2001 10:29 PM
> To: McNutt, Justin M.
> Subject: RE: I got stumped again...
>
> The date on this is 9Jan01; had you heard of this issue before?
> Ray
>
>
> <begin paste from
> https://support.nokia.com/knowledge/frmResolutionView.jsp?ResolutionId=434
> 5 >
>
> Resolution 4345
> tcpdump Vulnerable to a Denial of Service Attack
>
> IPSO (Operating system),
> for version: 3.2.1 And Before
>
> last update: 01/09/2001 17:37:55
> Upon receiving an IP packet with Protocol-4 and ihl=0, tcpdump enters an
> infinite loop within the procedure ip_print() (in print_ip.c). This
> happens because the header length (ihl) equals '0' and TCPDump tries to
> print the packet. On IPSO 3.2.1 and before, tcpdump would simply dump core
> when one of these packets are received.
>
> This vulnerability is not unique to IPSO (i.e. versions of FreeBSD, Linux,
> and Solaris have this problem as well). It can not be used to compromise
> your system.
>
> SOLUTION
> IPSO 3.3 and later do not suffer from this problem. Instead of dumping
> core, the following is displayed when these packets are received
>
> 17:42:58.376309 I
> 17:42:59.189242 I
> 17:42:59.700518 I
> 17:43:00.106992 I
>
> <end of paste>
>
>
> -----Original Message-----
> From: McNutt, Justin M.
> Sent: Monday, March 26, 2001 5:16 PM
> To: Shelton, Raymond A.
> Subject: RE: I got stumped again...
>
> > All of my examples are from default filters that come with
> > Shadow (see http://www.nswc.navy.mil/ISSEC/CID/step.htm .)
> >
> > In this example, for incoming ftp,
> >
> >
> > ip and not (src net 172.16 and dst net 172.16) and dst port 21 and
> > tcp[13] & 3 != 0
> >
> >
> > My assumption is that the "tcp[13] & 3 != 0" is trying to
> > test for the presence of a syn or fin;
> > do you agree? Is this to log connection setups and teardown
> > but not ongoing stream?
>
> Yes. TCP offset 13 is the second byte of the Flags word. The last two
> bits are SYN and FIN, respectively. A binary AND of these two bits
> against 3 (0b0011) will detect either of these two bits.
>
> A more interesting filter would detect whether or not BOTH bits were set
> (an obvious scan attempt, since there is no legitimate reason to set both
> bits). Such a filter would look like this:
>
> tcp[13] & 3 = 3
>
> To detect FTP servers in HSC, I would use the filter:
>
> dst net 161.130.0.0/16 and dst port 21 and tcp[13] & 2 = 2
>
> Some older tcpdump versions may not understand the /nn mask notation, so
> the following filter is equivalent:
>
> dst net 161.130.0.0 mask 255.255.0.0 and dst port 21 and tcp[13] & 2 = 2
>
> That will detect packets with the SYN bit set destined for an FTP server
> within your net block. You could do the tcp[13] & 3 version to also
> detect FINs, but over time, that's not going to catch anything that the
> more specific filter won't get (and the smaller the capture, the better
> IMHO).
>
> Hope that helps!
>
> --J