caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Xavier Leroy <Xavier.Leroy@inria.fr>
To: caml-list@inria.fr
Subject: Re: [Caml-list] Re: [oss-security] CVE request: Hash DoS vulnerability (ocert-2011-003)
Date: Mon, 12 Mar 2012 19:03:26 +0100	[thread overview]
Message-ID: <4F5E3A6E.4010406@inria.fr> (raw)
In-Reply-To: <20120310073113.GA16716@annexia.org>

On 03/10/2012 08:31 AM, Richard W.M. Jones wrote:

>> Rather than changing every app that uses Hashtbl, I'd prefer to fix
>> this upstream by choosing a random seed for hash tables unless the
>> caller explicitly sets one or sets an environment variable to disable
>> this.
>>
>> In Perl, the seed is a random number chosen when the Perl interpreter
>> starts up.  This is low overhead, but still leaves a (much more
>> theoretical) attack where someone can determine the seed from a
>> long-running process using some other method and still attack the hash
>> table.
>>
>> In Python there is an environment variable you can set to disable
>> randomized hash tables.  Further Python discussion here:
>> http://bugs.python.org/issue13703
>> http://mail.python.org/pipermail/python-dev/2012-January/thread.html#115465
> 
> No comment at all?  This is an exploitable CVE ...

As you and Gerd said, the new Hashtbl implementation in the upcoming
major release has everything needed to randomize hash tables by
seeding.  The question at this point is whether randomization should
be the default or not: some of our big users who don't do Web stuff
value reproducibility highly...  We (OCaml core developers) will take
a decision soon.

Musing: there is something strange about saying that a data structure
has a DOS vulnerability.  It's a bit like saying that a steak knife
has homicidal intent.  Web-facing applications that use the wrong data
structure have vulnerabilities; the data structure does not.  And,
even randomized, a hashtable still has O(n) worst-case behavior...

Gerd Stolpmann adds:

> Currently, the only way for library developers to fix their product for
> 3.12 is to restrict the size of the hashtables coming from untrusted
> sources.

A much better fix is to replace your hash tables with references to
AVL maps.  Guaranteed O(log n) is the way to go for Web app developers
to sleep soundly at night.

Resignedly awaiting a CVE about association lists,

- Xavier Leroy

  parent reply	other threads:[~2012-03-12 18:01 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4F3078F1.8070105@redhat.com>
2012-02-07  1:10 ` Kurt Seifried
2012-02-07  8:34   ` Richard W.M. Jones
2012-03-10  7:31     ` Richard W.M. Jones
2012-03-10 12:31       ` Gerd Stolpmann
2012-03-12 18:03       ` Xavier Leroy [this message]
2012-03-13  9:54         ` Romain Bardou
2012-03-13 11:58           ` Paolo Donadeo
2012-03-13 12:31             ` Philippe Veber
2012-03-13 13:23               ` Gerd Stolpmann
2012-03-13 15:39                 ` Romain Bardou
2012-03-13 18:27                   ` David Allsopp
2012-03-13 18:58                     ` Alain Frisch
2012-03-13 18:08                 ` Dario Teixeira
2012-03-13 18:28                   ` David Allsopp
2012-03-14  9:23                     ` Xavier Leroy
2012-03-13 16:52             ` Richard W.M. Jones

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=4F5E3A6E.4010406@inria.fr \
    --to=xavier.leroy@inria.fr \
    --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).