[web-devel] ANN: happstack-server 6.4.2 - import security update

Jeremy Shaw jeremy at n-heptane.com
Tue Dec 6 20:04:31 CET 2011


Hello,

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.



More information about the web-devel mailing list