Ethereal-users: [Ethereal-users] FW: I got stumped again...

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "McNutt, Justin M." <McNuttJ@xxxxxxxxxxxx>
Date: Tue, 27 Mar 2001 08:16:25 -0600
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