[Snort-sigs] new rule for detect SQL Ingres uuid_from_char() overflow

Matthew Watchinski mwatchinski at ...435...
Thu Jun 28 12:48:54 EDT 2007


Your thought process is very reasonable given the information available
in the advisory.  However, there are a number of additional things you
might want to take into consideration to write an effective rule.

When dealing with public advisories there is a lot of additional data
that is rarely disclosed. The net result is that there is a lot of
additional research that needs to be done. These public advisory "High
level overviews" don't normally contain complete or even accurate
vulnerability information.  Normally the discoverer knows a ton about
the vulnerability they are exploiting and that information isn't
reflected in a marketing focused advisory.  To accurately detect
attempts to exploit vulnerabilities the rule writer needs to know just
as much or even more than the discoverer of the vulnerability.

Just for some perspective this is a simple overview on how we deal with
vulnerability reports on the VRT.

1. Public advisory is released.
2. VRT develops a working Proof of Concept for the vulnerability.  This
requires installing the vulnerable software and configuring it correctly
so that it is in an attackable configuration.
2. Once the working PoC causes a crash it needs to be mutated to
determine what the complete set of triggering conditions is for this
particular vulnerability.  This includes things like spacing, syntax
variations, additional attack vectors, evasion, etc...
3. All triggering conditions need to be documented, results from the
disassembler needs to be logged to our bug tracking system, pcaps of
attack traffic, and pcaps of normal traffic need to be created.
4. At this point the rule creating process can begin.

After this a ton of regression testing and false positive/false negative
testing is done before the rule even makes it into our source code
repositories.

Given the above, the reason I asked the previous questions was to
highlight some of the other steps necessary to create effective coverage.

The main example is that the Ingres server only allocates 100 bytes on
the stack for storage, so anything more than 100 bytes overwrites other
data on the stack.  Therefore it is possible to exploit this
vulnerability with less than 200 bytes of data.

Additionally just as an FYI dsize doesn't deal with reassembled packets,
so it should only be used in very specific situations.  isdataat does
however deal with reassembled packets.

Cheers,
-matt

rmkml wrote:
> Hi Matt,
> 
>> 1. Why 200 if the stack buffer for this is 100 bytes?
> 
> well, read ngssoftware advisory: "If uuid_from_char is passed a long
> string as its argument, a stack...",
> if anyone have network traffic on ingres db ?
> 
>> 2. Why content:!")"; if an sql statement of this works
>> uuid_from_char( 'Ax100' )
> 
> I don't known if it is possible on this uuid_from_char()
> 
> 
>> Seems like the terminator would be ' and not )
> 
> Im search end line {)} (before return because sql), not "'" or '"'
> 
> 
>> 3. Why do a dsize, a isdataat and a within that all check essentially
>> the same thing?
> 
> yes, but dsize is more fast: check first big sql size, check second
> content and after isdataat
> 
> 
>> 4. Since this function is only suppose to convert text uuid's to byte
>> uuids why not just whitelist valid uuid's.  IE the function only takes
>> "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXX" and it must be formated like that.
> 
> good remark, but pcre is more slow than isdataat, maybe modified rules
> (v2) :
>  alert tcp $EXTERNAL_NET any -> $SQL_SERVERS 21064 (msg:"SQL Ingres
> uuid_from_char() overflow attempt";
>  flow:to_server,established; dsize:>200; content:" uuid_from_char(";
> nocase;
>  pcre:!"/
> uuid_from_char\(\s*('|")\d{8}\-\d{4}\-\d{4}\-\d{4}\-\d{12}('|")\s*\)/i";
>  reference:cve,2007-3338; reference:bugtraq,24585;
> classtype:attempted-user; sid:92036; rev:2;)
> 
> Best Regards
> Rmkml
> 
>> Cheers,
>> -matt
>>
>> rmkml wrote:
>>> Hi,
>>>
>>> please check and maybe add this new rule :
>>>
>>> alert tcp $EXTERNAL_NET any -> $SQL_SERVERS 21064 (msg:"SQL Ingres
>>> uuid_from_char() overflow attempt";
>  flow:to_server,established; dsize:>200; content:" uuid_from_char(";
> nocase;
>  isdataat:200,relative; content:!")"; within:200;
>  reference:cve,2007-3338; classtype:attempted-user; sid:92036; rev:1;)
>>>
>>> Any suggestions and improvements are welcome,
>>>
>>> Credits:
>>> Crusoe Researches
>>> http://www.Crusoe-Researches.com
>>> contact at ...3281...
>>> => Crusoe Researches have more than 2036 UNIQ 'snort' rules for
>>> Commercial Access
>>>      (Contact me directly if you are interested)
>>>
>>> Azwalaro French new nidps open source project
>>> http://www.Crusoe-Researches.com/azwalaro/
>>> azwalaro at ...3281...
>>>
>>> Regards
>>> Rmkml
>>>
>>> -------------------------------------------------------------------------
>>>
>>> This SF.net email is sponsored by DB2 Express
>>> Download DB2 Express C - the FREE version of DB2 express and take
>>> control of your XML. No limits. Just data. Click to get it now.
>>> http://sourceforge.net/powerbar/db2/
>>> _______________________________________________
>>> Snort-sigs mailing list
>>> Snort-sigs at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/snort-sigs
>>>
>>
>>
> 





More information about the Snort-sigs mailing list