From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q2ACVP1Z004731 for ; Sat, 10 Mar 2012 13:31:25 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsGAHtIW0/U4366k2dsb2JhbABCpAaRRiIBAQEBBwsUFAMkggoBAQQBbgsFCwUGGA0hRRIGEwkIAQmFdoF0CQe2YoJTh2KGTASNTBeacIFb X-IronPort-AV: E=Sophos;i="4.73,561,1325458800"; d="scan'208";a="148585434" Received: from moutng.kundenserver.de ([212.227.126.186]) by mail1-smtp-roc.national.inria.fr with ESMTP; 10 Mar 2012 13:31:19 +0100 Received: from office1.lan.sumadev.de (dslb-094-219-223-186.pools.arcor-ip.net [94.219.223.186]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0LkWsS-1SgmfO1Hka-00aSYT; Sat, 10 Mar 2012 13:31:15 +0100 Received: from gps.dynxs.de (localhost [127.0.0.1]) by office1.lan.sumadev.de (Postfix) with ESMTP id 78D1FC00CF; Sat, 10 Mar 2012 13:31:13 +0100 (CET) Received: from 178.4.239.185 (SquirrelMail authenticated user gerd) by gps.dynxs.de with HTTP; Sat, 10 Mar 2012 13:31:13 +0100 Message-ID: <0c153a3d432f9118bc6a46037ea8cb8a.squirrel@gps.dynxs.de> In-Reply-To: <20120310073113.GA16716@annexia.org> References: <4F3078F1.8070105@redhat.com> <4F3079F7.4040606@redhat.com> <20120207083412.GA30350@annexia.org> <20120310073113.GA16716@annexia.org> Date: Sat, 10 Mar 2012 13:31:13 +0100 From: "Gerd Stolpmann" To: "Richard W.M. Jones" Cc: caml-list@inria.fr User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal X-Provags-ID: V02:K0:l8FsV9X6AoadtVyWiylGXZomRIjeHUfMaiAb3UFlkg4 MRrBuig2D0dk1c6GTSg3QtZ/0GqTmnlaHKFrTMZhPeo1sPoOXH yZwMh6oNVXZHiH9NY1N7laxnvFv6nfHvTYpKU0OmeGhEvE2QIo AEltesi0l2WnzS8um3Nuf9U4hXSPUc1hkF4Td8Ea0MP9RdJ+gY cUct5qbhhTp5EFHQ1TNXDKYiM4mGpn9cdjC0l0aOvQKcDQD522 5E+eeXdMYLeyhcQWuX+hioZWGIMB+gdO0SfcjvDSxwjRMMZK1t KPZRaiPAgFKml2SASuHDQD5IQrgvSXTxg97J/QavqAWIkIH6al Sh/qZzJ4JkdFgcZrI6Wz/av90N8LGILacBk2a3acrP/evPrIUU 20rveprFdXorsOZUAmljnzeXr1FW4Hqf5Q= Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id q2ACVP1Z004731 Subject: Re: [Caml-list] Re: [oss-security] CVE request: Hash DoS vulnerability (ocert-2011-003) > On Tue, Feb 07, 2012 at 08:34:12AM +0000, Richard W.M. Jones wrote: >> On Mon, Feb 06, 2012 at 06:10:15PM -0700, Kurt Seifried wrote: >> > On 02/06/2012 06:05 PM, Kurt Seifried wrote: >> > > So going through various things looks like Ocaml is vulnerable and >> has >> > > not had a CVE # assigned for this issue yet. >> > > >> > > Discussion of the issue takes place on the mailing list, here is a >> link >> > > for the originating thread: >> > > >> > >cc >> > > >> > > There doesn't appear to be a fix yet. >> > > >> > > >> > >> > Please use CVE-2012-0839 for this issue. >> >> Red Hat BZ: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=787888 >> >> 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 ... Well, we discussed it already ( http://groups.google.com/group/fa.caml/browse_frm/thread/83d76b4869606c86/3c7eb9abe7d6aa50?tvc=1&q=hashtbl#3c7eb9abe7d6aa50 ), and there was no consensus that the "Perl way" is the preferrable one. OCaml 3.13 will provide options for Hashtbl allowing it pass a seed, but only in a case by case way. What will not be included in OCaml 3.13 is access to RNGs with entropy injection (i.e. it is left to the programmer to solve this difficulty). IMHO, the situation with 3.13 is not yet satisfying from a security standpoint, because Ocaml does not guide the developer to a safe solution. 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. For example, Ocamlnet-3.5.1 contains a fix for the HTTP and CGI protocol interpreters in this style. I don't know if there are fixes in other libraries. Gerd > > Rich. > > -- > Richard Jones > Red Hat > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa-roc.inria.fr/wws/info/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > > > -- 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 *** Searching for new projects! Need consulting for system *** programming in Ocaml? Gerd Stolpmann can help you.