This is not a problem "again". It's a known bug that has been around for
over a decade. But now servers are dropping because of it so its time to
patch and pray. I'm presenting a few options to tactically deal with
this issue below.
Ryan Barnett just spit out a new (impressive) mod security rule so you
can tactically patch without touching code (see below).
If anyone thinks this is "no big deal" then I feel they do not
understand the severity of this issue.
Respectfully,
Jim
****
First step is to inspect the ARGS and REQUEST_HEADERS data using a regex
to match on potential floating point payloads -
SecRule ARGS|REQUEST_HEADERS "[0-9\.]{12,}e-[0-9]{3,}"
"phase:2,t:none,t:lowercase,nolog,pass,exec:/usr/local/apache/conf/modsec_c
urrent/base_rules/FloatingPointDoSAttack.lua"
If a payload is found that matches the regex check, ModSecurity will
execute an external Lua script. The lua script then extracts out
payloads, strips out the "." and then searches for the MagicDoSNumber. If
this is found, then a TX variable is exported -
#################################
#!/opt/local/bin/lua
function main()
local Pattern = 2225073858507201;
-- Get the ModSec collections
local Headers = m.getvars("REQUEST_HEADERS");
local Args = m.getvars("ARGS");
for i = 1, #Headers do
FilteredPattern,NumChanges=string.gsub(Headers[i].value, "[.]", "")
if string.gmatch(FilteredPattern, Pattern) then
m.setvar("tx.floatingpointdos", Headers[i].name)
return ("Potential Floating Point DoS Attack via variable: "
..Headers[i].name .. ".");
end
end
for i = 1, #Args do
FilteredPattern,NumChanges=string.gsub(Args[i].value, "[.]", "")
if string.gmatch(FilteredPattern, Pattern) then
m.setvar("tx.floatingpointdos", Args[i].name)
return ("Potential Floating Point DoS Attack via variable: "
..Args[i].name .. ".");
end
end
return nil;
end
#################################
Then we have one follow-up rule that checks if the TX:FLOATINGPOINTDOS
variable is set -
SecRule TX:FLOATINGPOINTDOS ".*" "phase:2,t:none,log,block,msg:'Floating
Point DoS Payload Found.',logdata:'Location:
%{matched_var}',tag:'CVE-2010-4476'"
We have conducted some tests with different payloads and this appears to
work pretty well. If you find any issues please let me know.
Cheers,
Ryan
- Jim
> Anger growing....
>
> string -> number.
>
> it breaks,
>
> deal with it, and move on.
>
> why is this a problem again?
>
> On 15 Feb 2011, at 05:06, Chris Schmidt wrote:
>
>> I would assume just about any app with a shopping cart does. This is of
>> course compounded by libraries like struts and spring mvc that autobind your
>> form variables for you. Use a form with a double in it and your boned.
>>
>> Sent from my iPwn
>>
>> On Feb 14, 2011, at 8:57 AM, "Wall, Kevin" <kevin.w...@qwest.com> wrote:
>>
>>> Jim Manico wrote...
>>>> Rafal,
>>>>
>>>> It's not that tough to blacklist this vuln while you are waiting for your
>>>> team to patch your JVM (IBM and other JVM's have not even patched yet).
>>>> I've seen three generations of this filter already. Walk with me, Rafal and
>>>> I'll show you. :)
>>>>
>>>> 1) Generation 1 WAF rule (reject one number only)
>>>>
>>>> This mod security rule only blocks a small portion of the DOSable range.
>>>> The mod security team is working to improve this now (no disrespect meant
>>>> at all!)
>>>>
>>>> SecRule ARGS|REQUEST_HEADERS "@contains 2.2250738585072012e-308"
>>>> "phase:2,block,msg:'Java Floating Point DoS Attack',tag:'CVE-2010-4476'"
>>>>
>>>> Reference: http://mobile.twitter.com/modsecurity/status/35734652652093441
>>>>
>>>
>>> Depending how & when the exponent conversion is done, this mod_security rule
>>> may be completely ineffective. For example, if an attacker can write this
>>> floating point # as the equivalent
>>>
>>> 22.250738585072012e-309
>>>
>>> (which note, I have not tested), then the test above is invalid. I presumed
>>> that
>>> this was why Adobe's blacklist *first* removed the decimal point. Adobe's
>>> blacklist
>>> could be generalized a bit to cover appropriate ranges with a regular
>>> expression,
>>> but I agree wholeheartedly with you that what you dubbed as the "Chess
>>> Defense"
>>> (I like it) is the best approach short of getting a fix from the vendor of
>>> your
>>> JRE.
>>>
>>> So on a somewhat related note, does anyone have any idea as to how common
>>> it is for
>>> application developers to call ServletRequest.getLocale() or
>>> ServletRequest.getLocales()
>>> for Tomcat applications? Just curious. I'm sure it's a lot more common than
>>> developers using double-precision floating point in their applications (with
>>> the possible exception within the scientific computing community).
>>>
>>> -kevin
>>> ---
>>> Kevin W. Wall Qwest Risk Mgmt / Information Security
>>> kevin.w...@qwest.com Phone: 614.215.4788
>>> "It is practically impossible to teach good programming to students
>>> that have had a prior exposure to BASIC: as potential programmers
>>> they are mentally mutilated beyond hope of regeneration"
>>> - Edsger Dijkstra, How do we tell truths that matter?
>>> http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html
>>>
>>> This communication is the property of Qwest and may contain confidential or
>>> privileged information. Unauthorized use of this communication is strictly
>>> prohibited and may be unlawful. If you have received this communication
>>> in error, please immediately notify the sender by reply e-mail and destroy
>>> all copies of the communication and any attachments.
>>>
>>> _______________________________________________
>>> Secure Coding mailing list (SC-L) SC-L@securecoding.org
>>> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
>>> List charter available at - http://www.securecoding.org/list/charter.php
>>> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
>>> as a free, non-commercial service to the software security community.
>>> Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
>>> _______________________________________________
>>
>> _______________________________________________
>> Secure Coding mailing list (SC-L) SC-L@securecoding.org
>> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
>> List charter available at - http://www.securecoding.org/list/charter.php
>> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
>> as a free, non-commercial service to the software security community.
>> Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
>> _______________________________________________
>
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L@securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
> as a free, non-commercial service to the software security community.
> Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
> _______________________________________________
_______________________________________________
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
_______________________________________________
