[Snort-devel] [ snort-Bugs-505448 ] IDMEF XML not well formed large packets

noreply at ...12... noreply at ...12...
Sat Mar 23 18:58:14 EST 2002


Bugs item #505448, was opened at 2002-01-18 12:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=103357&aid=505448&group_id=3357

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDMEF XML not well formed large packets

Initial Comment:
I'm running 1.8.3 on Linux and OpenBSD, and I've
noticed that if I see a "Large ICMP packet", in this
case 7591 bytes, the <data> tag fails to close, along
with all other open tags except <event>. 

So, what I see is the end of the packet data, in hex,
followed by the </event>

So far, this is perfectly reproducable by just doing
and "nmap -sT addr" against the test Snort.

----------------------------------------------------------------------

Comment By: Roman Danyliw (danyliw)
Date: 2002-02-03 15:24

Message:
Logged In: YES 
user_id=136911

- This issue is not the same as #464851.  
- The title of this bug report is misleading, for this issue
is not in the IDMEF output plugin.  It is in the SNML XML
plugin

- The patch can be found below (and posted to snort-devel).

cheers,
Roman

[--snip--]

--- spo_xml.h.old	Sun Feb  3 15:14:59 2002
+++ spo_xml.h	Sun Feb  3 15:13:30 2002
@@ -54,11 +54,11 @@
 
 #define INDENT 2
 #define MAX_TAG_NAME 10
-#define MAX_TAG_VALUE 2048
+#define MAX_TAG_VALUE 32767
 #define MAX_ATTRIBUTE_NAME 10
 #define MAX_ATTRIBUTE_VALUE 16
 #define MAX_QUEUE 0
-#define MAX_ALERT_SIZE 8192
+#define MAX_ALERT_SIZE 65535
 #define MAX_SECOND_WAIT 60
 #define MAX_LEFT size - (buf - start)
 #define XMLMOD "xml_plugin: "

--- spo_xml.c.old2	Sun Feb  3 13:38:56 2002
+++ spo_xml.c	Sun Feb  3 15:11:16 2002
@@ -1381,7 +1381,10 @@
 
         if(ptr->value)
         {
-            snprintf(buf, MAX_LEFT, "%s", ptr->value);
+            if ( MAX_LEFT < MAX_TAG_VALUE )
+              snprintf(buf, MAX_LEFT, "%s", ptr->value);
+            else
+              snprintf(buf, MAX_TAG_VALUE, "%s",
ptr->value);
             buf += strlen(buf);
         }




----------------------------------------------------------------------

Comment By: David Greenstein (dgthistle)
Date: 2002-01-28 16:51

Message:
Logged In: YES 
user_id=441745

Yes. I've encountered the same problem. I can reproduce it 
generating a SNOT attack using the BACKDOOR SIGNATURE - Q 
ICMP attack (SID 183).

Running Linux 2.4.7 on i386.

I'm a bit confused with the followup... was this fixed with 
the patch submitted for #464851?


----------------------------------------------------------------------

Comment By: Roger Hand (rhand)
Date: 2002-01-25 15:39

Message:
Logged In: YES 
user_id=438914

Actually, this is being followed up as bug #464851.

----------------------------------------------------------------------

Comment By: Roger Hand (rhand)
Date: 2002-01-25 15:33

Message:
Logged In: YES 
user_id=438914

We've seen the same problem with "MISC Large ICMP Packet" 
(signature id 499). Packets that report a length of 1478 
or 1500 bytes show fine, but packets with a reported "len" 
of 28 bytes spew out thousands of characters of "data". 

As the original poster mentioned, the <data> and other 
tags fail to close (although the event tag itself closes), 
resulting in malformed xml.

The data itself sometimes appears to be random junk from 
within snort itself.  Could this be related to the 
following post I found on Google from June, 2001?:

Phil Wood wrote: > "In my case the problem of trash icmp 
types and codes is the result of a problem with snort.  It 
appears related to the defrag preprocessor.  I have 
documented, using tcpdump and snort in parallel, that 
valid ICMP packets (as seen by tcpdump), end up in snort 
with some memory (not associated with any packet) appended 
to a perfectly valid IP header (with proto of ICMP). 
Tcpdump shows two fragments (out of order) which together 
make up an icmp packet.  Snort's defrag constructs the 
complete ICMP packet with the identical IP header, but 
crud from some place in snort's memory as ICMP header and 
DATA"

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=103357&aid=505448&group_id=3357




More information about the Snort-devel mailing list