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@Crusoe-Researches.com
=> 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@Crusoe-Researches.com
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-sigs
-------------------------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-sigs
