Workaround for the JVM Double parsing vulnerability
David Pollak
There was a vulnerability identified on the JVM where a certain String, when parsed to a Double, would cause the current thread to hang.
To mitigate this issue, all direct calls to java.lang.Double.parseDouble and all calls to that method indirectly through Scala's .toDouble method have been replaced by calls to net.liftweb.common.ParseDouble.apply
ParseDouble throws an exception if the bad magic number is passed as a String.
This code is currently part of master and will be rolled into Lift 2.3-M1.
If you are a user of a prior version of Lift and need this patch applied to a prior version of Lift, please contact me privately with your application/URL so I can gauge the number of folks who cannot upgrade to 2.3-M1.
Thanks,
David
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im
Surf the harmonics
CM Lubinski
Hash: SHA1
This is helpful, but will still fail if one moves the decimal around:
22.250738585072012e-309
222.50738585072012e-310
etc.
Perhaps check for those digits and an appropriate negative exponent?
Thanks,
CM Lubinski
On 02/01/2011 11:44 AM, David Pollak wrote:
> Folks,
>
> There was a vulnerability identified on the JVM where a certain String, when
> parsed to a Double, would cause the current thread to hang.
>
> To mitigate this issue, all direct calls to java.lang.Double.parseDouble and
> all calls to that method indirectly through Scala's .toDouble method have
> been replaced by calls to net.liftweb.common.ParseDouble.apply
>
> ParseDouble throws an exception if the bad magic number is passed as a
> String.
>
> This code is currently part of master and will be rolled into Lift 2.3-M1.
>
> If you are a user of a prior version of Lift and need this patch applied to
> a prior version of Lift, please contact me privately with your
> application/URL so I can gauge the number of folks who cannot upgrade to
> 2.3-M1.
>
> Thanks,
>
> David
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAk1ITCQACgkQfzi1OiZiJLCi6wCfWN6hqeCnzGyMEGDHt0gGy9b5
0x4An2O0P7xQbq+4hc6V2AJvb0+Fp75X
=CG4x
-----END PGP SIGNATURE-----
Sander Mak
<feeder.of...@gmail.com> wrote:
> ParseDouble throws an exception if the bad magic number is passed as a
> String.
than throwing an exception?
Sander Mak
<feeder.of...@gmail.com> wrote:
> ParseDouble throws an exception if the bad magic number is passed as a
> String.
Or you could return the correct value (scala.Double.MinValue) rather
than throwing an exception?
Debilski
On 1 Feb., 19:17, Sander Mak <sander...@gmail.com> wrote:
> On Tue, Feb 1, 2011 at 6:44 PM, David Pollak
>
> > ParseDouble throws an exception if the bad magic number is passed as a
> > String.
>
> Or you could return the correct value (scala.Double.MinValue) rather
> than throwing an exception?
Sander Mak
<rikebenjami...@googlemail.com> wrote:
>
> scala.Double.MinValue is something else entirely.
Oh? I was looking for the Scala equivalent of
java.lang.Double.MIN_VALUE, found this:
scala.math.MIN_DOUBLE: The smallest possible value for scala.Double.
deprecated: Use scala.Double.MinValue instead
Hence my suggestion. But I looked up the ScalaDoc for
scala.Double,MinValue and found:
deprecated: use Double.MinNegativeValue instead
nice, chained deprecation. And that's when I found out the values
differ as well (and that's probably what you meant). Interesting.
Sander Mak
<rikebenjami...@googlemail.com> wrote:
> scala.Double.MinValue is something else entirely.
Yeah, I misread DBL_MIN (which is apparently the smallest normalized
positive floating-point double) to mean the MIN_VALUE of the Double
type, which is indeed an entirely different number. Still, my point
stands that there *is* a correct value that can be returned for the
'magic double of death'.
Debilski
On 1 Feb., 20:45, Sander Mak <sander...@gmail.com> wrote:
> On Tue, Feb 1, 2011 at 8:06 PM, Debilski
>
> > scala.Double.MinValue is something else entirely.
>
> Yeah, I misread DBL_MIN (which is apparently the smallest normalized
> positive floating-point double) to mean the MIN_VALUE of the Double
> type, which is indeed an entirely different number. Still, my point
> stands that there *is* a correct value that can be returned for the
> 'magic double of death'.
math.pow(2, -1022) (or even math.pow(2, -1022) - math.pow(2, -1074)).
But on the other hand, I don’t know enough about IEEE numbers on the
JVM… (And also, is the smallest normalised double the same on all
JVMs?)
Sander Mak
http://blog.headius.com/2011/02/working-around-java-doubleparsedouble.html
> --
> You received this message because you are subscribed to the Google Groups "Lift" group.
> To post to this group, send email to lif...@googlegroups.com.
> To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
>
>
David Pollak
Charlie Nutter from JRuby explains their workaround:
http://blog.headius.com/2011/02/working-around-java-doubleparsedouble.html
I'm going to re-open the ticket and let the dust settle on the best solution to the issue before updating Lift.
Indrajit Raychaudhuri
with this in older JVMs [2].
Further Oracle (Apple in case of OS X) have pushed out newer
maintenance versions of JVM for the platforms on which Lift runs.
So unless there is any strong reason for the contrary, I'm proposing
deprecation and eventual removal of ParseDouble.
Thoughts/Opinions?
- Indrajit
[1] http://blogs.oracle.com/security/entry/security_alert_for_cve-2010-44
[2] http://www.oracle.com/technetwork/java/javase/fpupdater-tool-readme-305936.html
On Friday 4 February 2011 at 4:49 AM, David Pollak wrote:
>
>
> On Wed, Feb 2, 2011 at 12:24 PM, Sander Mak <sand...@gmail.com (mailto:sand...@gmail.com)> wrote:
> > Charlie Nutter from JRuby explains their workaround:
> > http://blog.headius.com/2011/02/working-around-java-doubleparsedouble.html
>
> I'm going to re-open the ticket and let the dust settle on the best solution to the issue before updating Lift.
> > On Tue, Feb 1, 2011 at 9:27 PM, Debilski
> > <rikebenjami...@googlemail.com (mailto:rikebenjami...@googlemail.com)> wrote:
> > >
> > >
> > > On 1 Feb., 20:45, Sander Mak <sander...@gmail.com (mailto:sander...@gmail.com)> wrote:
> > > > On Tue, Feb 1, 2011 at 8:06 PM, Debilski
> > > >
> > > > <rikebenjamin.schupp...@googlemail.com (mailto:rikebenjamin.schupp...@googlemail.com)> wrote:
> > > > > scala.Double.MinValue is something else entirely.
> > > >
> > > > Yeah, I misread DBL_MIN (which is apparently the smallest normalized
> > > > positive floating-point double) to mean the MIN_VALUE of the Double
> > > > type, which is indeed an entirely different number. Still, my point
> > > > stands that there *is* a correct value that can be returned for the
> > > > 'magic double of death'.
> > >
> > > From reading some articles, I guess the number should be rounded(?) to
> > > math.pow(2, -1022) (or even math.pow(2, -1022) - math.pow(2, -1074)).
> > > But on the other hand, I don’t know enough about IEEE numbers on the
> > > JVM… (And also, is the smallest normalised double the same on all
> > > JVMs?)
> > >
> > > --
> > > You received this message because you are subscribed to the Google Groups "Lift" group.
> > > To post to this group, send email to lif...@googlegroups.com (mailto:lif...@googlegroups.com).
> > > To unsubscribe from this group, send email to liftweb+u...@googlegroups.com (mailto:liftweb%2Bunsu...@googlegroups.com).
> > > For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
> >
> > --
> > You received this message because you are subscribed to the Google Groups "Lift" group.
> > To post to this group, send email to lif...@googlegroups.com (mailto:lif...@googlegroups.com).
> > To unsubscribe from this group, send email to liftweb+u...@googlegroups.com (mailto:liftweb%2Bunsu...@googlegroups.com).
> > For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Blog: http://goodstuff.im
> Surf the harmonics
> --
> You received this message because you are subscribed to the Google Groups "Lift" group.
> To post to this group, send email to lif...@googlegroups.com (mailto:lif...@googlegroups.com).
> To unsubscribe from this group, send email to liftweb+u...@googlegroups.com (mailto:liftweb+u...@googlegroups.com).
Peter Robinett
Indrajit Raychaudhuri
Assuming a modern hosting or dev environment that support those conditions, it's almost certainly going to be a variant of Linux, Windows or OS X. I'd imagine one wouldn't purposely want to host an application on a JVM with documented security issue when an upgrade is available :)
[1] http://www.assembla.com/spaces/liftweb/wiki/Getting_Started
- Indrajit
On Tuesday 19 July 2011 at 12:21 AM, Peter Robinett wrote:
> I guess the question is, what JVMs and versions does Lift support? I'm not sure...
>
> Peter
>
> --
> You received this message because you are subscribed to the Google Groups "Lift" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/liftweb/-/Hc4O798rHkYJ.