ANN: happstack-server 6.4.2 - import security update
Jeremy Shaw
I have uploaded a new version of happstack-server to hackage. The new
version fixes a possible denial of service attack discovered by
Gracjan Polak.
The Read instances for integral types can be abused to created very
large numbers. For example:
> main = print (read "1e10000000000000" :: Integer)
will cause the app to attempt to allocate enough ram to hold an
Integer with all those zeros. This effects all integer types such as
Int, Int8, Word, etc. because their 'read' instances first read things
into an Integer.
The 'fix' is to use 'readDec' instead of 'read' for Integral values.
In this release we make the following changes:
1. change all internal uses of read to readDec
2. change the integral instances for FromReqURI to use readDec (as
implied by #1)
3. the readRq helper function in RqData now uses FromReqURI instances
instead of Read
4. the old readRq function is now called unsafeReadRq.
5. exported: readDec' :: (Num a) => String -> Maybe a, which is just
a wrapper around readDec with a friendlier type.
Unfortunately, there are still some issues we can't do anything about.
For example, if users (that means *you*) have written:
> do i <- read <$> look "int"
Then only you can fix it.
Also, if you create a type that embeds integral types:
> newtype MyId = MyId { unMyId :: Integer } deriving (Show, Read)
That is still affected by the read issue. If you create a FromReqURI
instance, you better not use 'read'.
So, 'read' is still a hidden danger to users that do not know about
this pitfall. Not sure what we can do about it -- aside from changing
the behavior of Read. It is not clear to me if this behavior is
defined by H98, or a special 'feature' of GHC. However, this issue
affects all applications which attempt to use 'read' on untrusted
data, not just Happstack.
In happier news, happstack-server no longer depends on happstack-util
(or happstack-anything-else). The tradeoff is that it does add a
dependency on base64-bytestring. The upshot is that we can now
deprecate happstack-util and all the cruft that has accumulated in
there. Less code to maintain == happier maintainers.
- jeremy
p.s. actually. building with -ftests probably still requires
happstack-util.. for now. But all the tests should be moved into a
separate library anyway, which will resolve that issue.
Gracjan Polak
On 6 Gru, 20:04, Jeremy Shaw <jer...@n-heptane.com> wrote:
>
> > main = print (read "1e10000000000000" :: Integer)
>
You may track this bug here:
http://hackage.haskell.org/trac/ghc/ticket/5688
> So, 'read' is still a hidden danger to users that do not know about
> this pitfall. Not sure what we can do about it -- aside from changing
> the behavior of Read. It is not clear to me if this behavior is
> defined by H98, or a special 'feature' of GHC.
Haskell Report defines integers as those that *contain neither decimal
dot nor exponent*.
http://www.haskell.org/onlinereport/haskell2010/haskellch2.html#x7-190002.5
So we have Report violation here.
However Rational, Double and Float will still be affected even if
Integer case was fixed.
I'm working on a more general fix.
--
Gracjan
Jeremy Shaw
is too common to be unsafe like that.
- jeremy
> --
> You received this message because you are subscribed to the Google Groups "HAppS" group.
> To post to this group, send email to ha...@googlegroups.com.
> To unsubscribe from this group, send email to happs+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/happs?hl=en.
>