caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Gerd Stolpmann <info@gerd-stolpmann.de>
To: caml-list@inria.fr
Subject: [Caml-list] Hashtbl and security
Date: Fri, 30 Dec 2011 17:44:06 +0100	[thread overview]
Message-ID: <1325263446.5036.104.camel@samsung> (raw)

Hi,

there was recently a security alert for web services that use hash
tables to store web form parameters sent via POST (so that millions of
such parameters can be sent in a single request). It is possible to keep
the web service busy for hours with such a DoS (denial of service)
attack. The type of attack boils down to a problem in most hash table
implementations, namely that the hash functions are invertible, and it
is possible for a malicious user to construct lots of keys that all map
to the same bucket of the hash table, creating a mass collision.

The text of the alert: 
http://www.nruns.com/_downloads/advisory28122011.pdf

I'd like to discuss this issue, because it is not restricted to the
processing of web requests, but may also occur for all other data coming
from untrusted sources. The web is only the most exposed area where this
issue exists.

So how is Ocaml affected? The hash functions used in recent Ocaml
releases are also insecure in the above mentioned sense (currently
MurmurHash3, and even a simpler hash function in previous releases). A
quick survey of the Internet revealed at least one site that tries to
break it. Probably a good cryptographer could do it in minutes. 

A pure Hashtbl.add of the constructed keys does not yet lead to the
performance degradation, but a Hashtbl.replace, and of course
Hashtbl.find after the table is built up will. So it depends very much
of the details of the programs whether they are affected or not.

I've just checked that Ocamlnet uses only Hashtbl.add to collect POST
parameters, so it is not directly vulnerable. But if the crafted request
is actually served by a handler, the handler would get a degraded table,
and could show in turn bad performance (again leading to DoS).

What are possible fixes?

1) Avoid hash tables in contexts where security is relevant. The
alternative is Set (actually a balanced binary tree), which does not
show this problem.

2) Use cryptographically secure hash functions.

3) Use "randomized" hash tables. The trick here is that there is not a
single hash function h anymore, but a family h(1)...h(n). When the hash
table is created, one of the functions is picked randomly. This makes it
impossible to craft an attack request, because you cannot predict the
function.

I don't think 1) is viable - hash tables are too wide spread, and are
loved by programmers because of their good performance. 2) would be good
in extremely critical contexts - although it is then again questionable,
because it is likely to have worse performance than 1).

So, the question is how to do 3). I see two problems here:

a) how to define the family of hash functions. Is it e.g. sufficient to
introduce an initialization vector for the Murmurhash algorithm, and
fill it randomly? How to get a random number that is good enough?

b) the Hashtbl in the standard library does not allow it to set the hash
function dynamically. Maybe one can get this effect by using first-class
modules (haven't checked).

Anyway, I think these problems are difficult enough to deserve some
discussion here. At least I cannot solve them immediately, and this
problem may exist for lots of Ocaml applications.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
Creator of GODI and camlcity.org.
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------


             reply	other threads:[~2011-12-30 16:44 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-30 16:44 Gerd Stolpmann [this message]
2011-12-30 16:48 ` Yaron Minsky
2011-12-30 19:01   ` David Allsopp
2011-12-30 20:52     ` Yaron Minsky
2011-12-30 21:54       ` Gerd Stolpmann
2011-12-30 17:06 ` Xavier Leroy
2011-12-30 21:16   ` Gerd Stolpmann
2011-12-31  0:57   ` oliver
2011-12-31  0:59     ` oliver
2012-01-01 12:52   ` Richard W.M. Jones
2012-01-01 17:29     ` Xavier Leroy
2012-01-01 21:04       ` Gerd Stolpmann
2012-01-01 23:24         ` oliver
2012-01-01 23:58           ` Gerd Stolpmann
2012-01-02  1:43             ` oliver
2012-01-04 17:56               ` Damien Doligez
2012-01-04 21:52                 ` oliver
2012-01-02  9:34         ` David MENTRE
2012-01-30 10:54       ` Goswin von Brederlow
2011-12-30 17:40 ` rixed
2011-12-30 17:52   ` Edgar Friendly
2011-12-31  1:02   ` oliver
2011-12-31  0:33 ` oliver
2012-01-02  0:21 ` Shawn Wagner
2012-01-02 14:52   ` Gerd Stolpmann
2012-01-30 10:51 ` Goswin von Brederlow
2012-01-31 14:16   ` Gerd Stolpmann
2012-02-08  9:41     ` Goswin von Brederlow
2012-02-08 10:43       ` Philippe Wang
2012-02-08 10:46       ` AUGER Cédric
2012-02-09 13:22         ` Goswin von Brederlow
2012-02-09 14:48           ` Gerd Stolpmann
2012-02-08 11:12       ` Gerd Stolpmann
2012-02-09 13:11         ` Goswin von Brederlow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1325263446.5036.104.camel@samsung \
    --to=info@gerd-stolpmann.de \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).