From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q2DIwlh2003207 for ; Tue, 13 Mar 2012 19:58:47 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIKAKuXX0/B/BfVcmdsb2JhbABDgwmvW4MpAQwIFRQDJIIJAQEFOEABEAsOCgkWDwkDAgECAUUGDQEHAQGICrwGkGUElVCFaY0g X-IronPort-AV: E=Sophos;i="4.73,578,1325458800"; d="scan'208";a="135888177" Received: from msa04.smtpout.orange.fr (HELO msa.smtpout.orange.fr) ([193.252.23.213]) by mail4-smtp-sop.national.inria.fr with ESMTP; 13 Mar 2012 19:58:42 +0100 Received: from [192.168.1.105] ([86.195.6.62]) by mwinf5d16 with ME id l6yg1i00Q1LHk3a036yht6; Tue, 13 Mar 2012 19:58:41 +0100 Message-ID: <4F5F98DA.8080806@frisch.fr> Date: Tue, 13 Mar 2012 19:58:34 +0100 From: Alain Frisch User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: David Allsopp CC: Romain Bardou , "caml-list@inria.fr" References: <4F3078F1.8070105@redhat.com> <4F3079F7.4040606@redhat.com> <20120207083412.GA30350@annexia.org> <20120310073113.GA16716@annexia.org> <4F5E3A6E.4010406@inria.fr> <4F5F1968.20600@lsv.ens-cachan.fr> <4ec32a156daa6211ca4d465c9a7b8745.squirrel@gps.dynxs.de> <4F5F6A44.2070601@lsv.ens-cachan.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] Re: [oss-security] CVE request: Hash DoS vulnerability (ocert-2011-003) On 03/13/2012 07:27 PM, David Allsopp wrote: > +1. Surely in projects where repeatability is important, the change in behaviour to randomly seeded tables would be quickly noticed The problem is that the randomization might go unnoticed if the high-level outputs of the program does not depend on the ordering when enumerating the hash table (because the "interesting" algorithms built above the hash table is supposed to be invariant w.r.t. the ordering of their input). So the programmer doesn't turn randomization off, but one day, the end-user discovers a bug (caused by a very subtle bug in the algorithm, which in fact, depends on the ordering), and one cannot reproduce it. Ocsigen and other web libraries can decide to turn randomization on by default to protect their users, but for a general purpose programming system like OCaml's stdlib, increasing reproducibility seems more important than protecting programmers from high-level defects (possibility of DoS) caused by a poor choice or use of low-level data structure. Alain