Re: [WEB SECURITY] Re: [Webappsec] Corsaire whitepaper: Breaking the Bank (Vulnerabilities in Numeric Processing within Financial Applications)

[Jim Manico <jim@xxxxxxxxxx>]

> Jim, unless I misunderstand something, none of the issues described 
in the paper are "vulnerabilities" in the languages

I think the rounding errors could lead to vulnerabilities in some 
financial applications. Since this flaw is still present in the latest 
versions of Java 5, at least, it might be worth bringing this to Sun's 
attention again. I'd also be curious if this flaw exists in non-Sun JVM's.

As a side note, we do the Infinite and NaN checking in the ESAPI default 
implementation for double verification, at least.

For your consideration:

   /**
    * Returns a validated number as a double. Invalid input
    * will generate a descriptive ValidationException, and input that 
is clearly an attack
    * will generate a descriptive IntrusionException.
    */
   public Double getValidDouble(String context, String input, double 
minValue, double maxValue, boolean allowNull) throws 
ValidationException, IntrusionException {
       if (minValue > maxValue) {
           //should this be a RunTime?
           throw new ValidationException( context + ": Invalid double 
input: context", "Validation parameter error for double: maxValue ( " + 
maxValue + ") must be greater than minValue ( " + minValue + ") for " + 
context );
       }
       
       if (isEmpty(input)) {
           if (allowNull) return null;
              throw new ValidationException( context + ": Input 
required: context", "Input required: context=" + context + ", input=" + 
input );
       }
       
       try {
           Double d = new Double(Double.parseDouble(input));
           if (d.isInfinite()) throw new ValidationException( "Invalid 
double input: context=" + context, "Invalid double input is infinite: 
context=" + context + ", input=" + input );
           if (d.isNaN()) throw new ValidationException( "Invalid 
double input: context=" + context, "Invalid double input is infinite: 
context=" + context + ", input=" + input );
           if (d.doubleValue() < minValue) throw new 
ValidationException( "Invalid double input must be between " + minValue 
+ " and " + maxValue + ": context=" + context, "Invalid double input 
must be between " + minValue + " and " + maxValue + ": context=" + 
context + ", input=" + input );
           if (d.doubleValue() > maxValue) throw new 
ValidationException( "Invalid double input must be between " + minValue 
+ " and " + maxValue + ": context=" + context, "Invalid double input 
must be between " + minValue + " and " + maxValue + ": context=" + 
context + ", input=" + input );
           
           return d;
       } catch (NumberFormatException e) {
           throw new ValidationException( context + ": Invalid double 
input", "Invalid double input format: context=" + context + ", input=" + 
input, e);
       }
   }

> This is nice work.  At the beginning, reading about the problems with 
> using floating point or double values for financial values, I was 
> thinking "yeah, yeah programming 101", and personally I think that the 
> bit about many small transactions which round favorably (i.e. the 
> currency exchange type problem) is also fairly well known.  However, I 
> think there is much less awareness of thing such as using "NaN" or 
> "Infinity" in inputs to bypass filters.  I know I'll be playing around 
> with the related attacks for a bit to get a feel for them.
>
> Jim Manico wrote:
> > This is a very interesting article, nice work.
> >
> > I would recommend you add *exact* versions of the various API's being 
> > used.
> >
> > At the very least, all of your Java samples do indeed check out 
> > against Java 1.5_0_16 on Windows.
> >
> > Have you reported these issues to Sun/Microsoft?
>
> Jim, unless I misunderstand something, none of the issues described in 
> the paper are "vulnerabilities" in the languages (which are the only 
> Sun/Microsoft products mentioned I believe).  Instead, behavior of the 
> language which may not be immediately obvious to all programmers 
> writing web applications is discussed.  In other words, if you fail to 
> account for the language behavior when interpreting "NaN" as a valid 
> number your application may be vulnerable, but that is not to say that 
> Java is.  As such, reporting/embargoes/etc seems not to apply.
>
> -Nathanael
>
> > - Jim
> > > Breaking the Bank
> > > (Vulnerabilities in Numeric Processing within Financial Applications)
> > >
> > > By Adam Boulton, Stephen De Vries, Kevin O'Reilly, July 15, 2008


--
Jim Manico, Senior Application Security Engineer
jim.manico@xxxxxxxxxxxxxxxxxx | jim@xxxxxxxxxx
(301) 604-4882 (work)
(808) 652-3805 (cell)

Aspect Security™
Securing your applications at the source
http://www.aspectsecurity.com


----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA