[Snort-users] flexresp3: Reset with TTL of 0
rcombs at ...1935...
Tue Oct 26 17:45:16 EDT 2010
If you send a pcap I'll have a look. Some comments below.
On Tue, Oct 26, 2010 at 5:27 PM, Jim Hranicky <jfh at ...5250...> wrote:
> On Tue, 26 Oct 2010 14:32:01 -0400
> Jim Hranicky <jfh at ...5250...> wrote:
> > Has anyone else seen this behavior? I've likely missed a step somewhere.
> > I'll be glad to supply more info if needed.
> Sorry for the double post. I forgot to mention the OS:
> 2.6.32-24-server #39-Ubuntu SMP Wed Jul 28 06:21:40 UTC 2010 x86_64
> The sniff interface is an Intel X520 and I've compiled PF_RING support into
> I went ahead and attached a gdb to one of the running snorts. I set it to
> in active.c:Active_SendReset() and then triggered the reset:
> #0 Active_SendReset (p=0x7ffffaf9f980, ef=2147483648) at active.c:214
> #1 0x000000000046ab51 in Resp3_Send (p=0x7ffffaf9f980, pv=0x362bf30) at
> #2 0x000000000040d971 in Active_SendResponses (p=0x7ffffaf9f980) at
> #3 0x000000000042a6f8 in ProcessPacket (user=0x0, pkthdr=0x7ffffafa07b0,
> pkt=0x3aac070 "", ft=0x0) at snort.c:1484
> #4 0x000000000042a3cd in PacketCallback (user=0x0, pkthdr=0x7ffffafa07b0,
> pkt=0x3aac070 "") at snort.c:1382
> #5 0x00000000004d6f6a in pcap_process_loop ()
> #6 0x00007f904e5cb514 in pcap_read_linux () from
> #7 0x00000000004d7026 in pcap_daq_acquire ()
> #8 0x00000000004d4342 in daq_acquire ()
> #9 0x00000000004494a8 in DAQ_Acquire (max=-1, callback=0x42a307
> <PacketCallback>, user=0x0) at sfdaq.c:453
> #10 0x000000000042cb29 in PacketLoop () at snort.c:2757
> #11 0x000000000042957a in SnortMain (argc=9, argv=0x7ffffafa0b68) at
> #12 0x000000000042948d in main (argc=9, argv=0x7ffffafa0b68) at
> Then stepped into this function
> rej = Encode_Reject(ENC_TCP_RST, flags|value, p, &len);
> which took me here:
> #0 Eth_Encode (enc=0x7ffffaf9f860, in=0x7ffffaf9f7f0, out=0x7ffffaf9f7d0)
> at encode.c:502
> #1 0x000000000040c357 in Encode_Packet (enc=0x7ffffaf9f860,
> p=0x7ffffaf9f980, len=0x7ffffaf9f8d0) at encode.c:355
> #2 0x000000000040bdd5 in Encode_Reject (type=ENC_TCP_RST,
> flags=2684354560, p=0x7ffffaf9f980, len=0x7ffffaf9f8d0) at encode.c:175
> after coming out I printed the value of rej in hex:
> (gdb) x/64x rej
> 0x739b20 <s_pkt>: 0x00 0x0e 0x83 0xc6 0xa3 0x40
> 0x00 0xd0
> 0x739b28 <s_pkt+8>: 0x02 0x1c 0xf0 0x00 0x08 0x00
> 0x45 0x00
> 0x739b30 <s_pkt+16>: 0x00 0x28 0x33 0xfd 0x00 0x00
> 0x00 0x06
Next to last byte should be ttl and it is zero.
> 0x739b38 <s_pkt+24>: 0x24 0x4a [ ... ]
> If I'm not mistaken, the ttl should be at byte 22 and is 0 in this case.
> At one point I appeared to trip a Heisenbug and actually got a ttl of 64
> shown in tcpdump,
> but that only happened once or twice in the call of Active_SendReset() .
The encoder tries to use the TTL from the session which may explain why you
see it vary.
> Also, stepping through the code it looks like rej is actually a pointer to
> a static
> variable, so the next line
> if ( !rej ) return;
> will never trigger a return unless I'm mistaken. I don't know if that's a
> factor here
> or not.
It being static doesn't mean that the return can't be something else - like
NULL, which is returned instead of the static upon error.
> Is this enough to file a bug report? I can send pcaps & whatnot. OTOH, it's
> possible I'm wildly wrong :-)
> We don't have external bug reports apart from these postings and this does
look like something isn't quite right. I will file an internal bug with
your pcap after verifying your results.
> Jim Hranicky
> IT Security Engineer
> Office of Information Security and Compliance
> University of Florida
> Nokia and AT&T present the 2010 Calling All Innovators-North America
> Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> Snort-users mailing list
> Snort-users at lists.sourceforge.net
> Go to this URL to change user options or unsubscribe:
> Snort-users list archive:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Snort-users