[Snort-sigs] FPs on 3632 ("WEB-CLIENT Mozilla bitmap width integer overflow attempt)

Jeff Kell jeff-kell at ...922...
Wed Jan 11 18:00:11 EST 2006


This signature is generating some FPs when the literal "BM" occurs 
between the Content-type: header and the beginning of the file.

The rule is looking for an overflow in the width using:
> pcre:"/^Content-type\x3a\s*image\x2fbmp/smi"; content:"BM"; distance:0; byte_test:4,>,83386080,16,relative,little;

It needs to anchor the start of the file data offset, e.g.:
>    pcre:"/^Content-type\x3a\s*image\x2fbmp/smi"; content:"|0D0A0D0A|"; distance:0; content:"BM"; distance:0; byte_test:4,>,83386080,16,relative,little;

Example of FP data capture (partial packet):

> 170 :                                  54 72 61 6E 73              Trans
> 180 : 66 65 72 2D 45 6E 63 6F 64 69 6E 67 3A 20 63 68   fer-Encoding: ch
> 190 : 75 6E 6B 65 64 0D 0A 43 6F 6E 74 65 6E 74 2D 54   unked..Content-T
> 1a0 : 79 70 65 3A 20 69 6D 61 67 65 2F 62 6D 70 3B 20   ype: image/bmp; 
> 1b0 : 66 69 6C 65 6E 61 6D 65 3D 22 66 6F 6F 2E 62 61   filename="foo.ba
> 1c0 : 72 22 0D 0A 53 65 74 2D 43 6F 6F 6B 69 65 3A 20   r"..Set-Cookie: 
> 1d0 : 59 4D 42 4D 3D 64 3D 26 76 3D 31 3B 20 70 61 74   YMBM=d=&v=1; pat
> 1e0 : 68 3D 2F 3B 20 64 6F 6D 61 69 6E 3D 2E 79 61 68   h=/; domain=.yah
> 1f0 : 6F 6F 2E 63 6F 6D 0D 0A 0D 0A 66 64 66 64 20 20   oo.com....fdfd  
> 200 : 20 0D 0A 42 4D AE 2B 01 00 00 00 00 00 36 04 00    ..BM.+......6..
> 210 : 00 28 00 00 00 F5 00 00 00 31 01 00 00 01 00 08   .(.......1......

Note the cookie "YMBM" -- the original sig content:"BM" picks that up 
instead of the proper file header.  The same "BM" chars in the filename 
would also misfire this alert.  Anchoring the test after the HTTP header 
avoids this confusion.

The revised rule could use a within:2 if not for the possible chunked 
encoding (which is present here).  Tweaking that part is left as an 
excercise for the reader.

Jeff




More information about the Snort-sigs mailing list