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 q2DIRwaX001982 for ; Tue, 13 Mar 2012 19:27:58 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAEANKQX09RZ90wlGdsb2JhbABDsmSDByIBAQEBCQsSFAMkggkBAQEEgQkCAQgYCiQyJQIEARqIAwO8GZACYwSIIo0ukwg X-IronPort-AV: E=Sophos;i="4.73,578,1325458800"; d="scan'208";a="149160638" Received: from mtaout02-winn.ispmail.ntl.com ([81.103.221.48]) by mail1-smtp-roc.national.inria.fr with ESMTP; 13 Mar 2012 19:27:52 +0100 Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20120313182751.QLSN20752.mtaout02-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com>; Tue, 13 Mar 2012 18:27:51 +0000 Received: from romulus.metastack.com ([81.102.132.77]) by aamtaout01-winn.ispmail.ntl.com (InterMail vG.3.00.04.00 201-2196-133-20080908) with ESMTP id <20120313182751.ILBD10211.aamtaout01-winn.ispmail.ntl.com@romulus.metastack.com>; Tue, 13 Mar 2012 18:27:51 +0000 Received: from remus.metastack.local (remus.metastack.com [172.16.0.1]) by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id q2DIRmao018134 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Mar 2012 18:27:48 GMT Received: from Remus.metastack.local ([fe80::547c:3c42:e1da:eda2]) by Remus.metastack.local ([fe80::547c:3c42:e1da:eda2%10]) with mapi id 14.01.0355.002; Tue, 13 Mar 2012 18:27:48 +0000 From: David Allsopp To: Romain Bardou , "caml-list@inria.fr" Thread-Topic: [Caml-list] Re: [oss-security] CVE request: Hash DoS vulnerability (ocert-2011-003) Thread-Index: AQHM5TxKH1XM0INoOESjbBaqMVzrEZYxHBAAgDI5AYCAA9VOAIABCc8AgAAie4CAAAlZAIAADmmAgAAmJwCAACsS0A== Date: Tue, 13 Mar 2012 18:27:47 +0000 Message-ID: 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: <4F5F6A44.2070601@lsv.ens-cachan.fr> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.0.7] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Organization: MetaStack Solutions Ltd. X-Scanned-By: MIMEDefang 2.65 on 172.16.0.20 X-Cloudmark-Analysis: v=1.1 cv=R50lirqlHffDPPkwUlkuVa99MrvKdVWo//yz83qex8g= c=1 sm=0 a=40hZHaDki8MA:10 a=V8lMrATVidEA:10 a=cTs9vV391PwA:10 a=8nJEP1OIZ-IA:10 a=xqWC_Br6kY4A:10 a=kSqVSOvHY6WujaHmi_kA:9 a=MJPpBv2lJshzwGcx2_QA:7 a=wPNLvfGTeEIA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id q2DIRwaX001982 Subject: RE: [Caml-list] Re: [oss-security] CVE request: Hash DoS vulnerability (ocert-2011-003) Romain Bardou wrote: > Le 13/03/2012 14:23, Gerd Stolpmann a écrit : > > > >> The best compromise to me is to leave the default for Hashtbl, but > >> properly document this aspect in the manual (with succint explanation > >> and one relevant pointer). That way: > >> - you don't break compatibility > >> - you keep default reproducibility (which is a real feature) > >> - you teach beginners like myself on tough aspects related to the use > >> of a datastructure in some frequent use cases. > > > > Basically I like the idea of "teaching" users this way. The typical > > user will understand the impact, and act accordingly. Nevertheless, I > > would like it if it would be made as easy as possible to provide good > > seeds if required. The Random module is definitely not good enough > > (e.g. if you know when the program was started like for a cgi, and the > > cgi reveals information it should better not like the pid, the Random > > seed is made from less than 10 unpredictable bits, and on some systems > even 0 bits). > > > > The ideal would be to guide the user to the decision whether > > protection is necessary, and if the answer is yes, to give the > > instructions how to do it (and provide all means for it, of course). > > This teaching idea sounds great indeed, but on the other hand, where do > we draw the line? If we push this reasoning too far, we could remove > typing altogether and just tell the programmer to be careful. What is the > difference here? Is a potential DoS attack "less bad" than a seg fault? > > So although the idea of teaching the programmer through the documentation > makes sense, I would put it the other way around: make the safer behavior > the default, and give debugging tools with proper warnings. Here the tool > is a "set_seed" function and the warning is in its documentation: "using > the same seed everytime can lead to DoS attacks". +1. Surely in projects where repeatability is important, the change in behaviour to randomly seeded tables would be quickly noticed (and can be quickly solved, if the appropriate "set_seed" or whatever is there) through failing unit tests and so on, surely? Repeatability seems the more niche use of a hash table, IMHO, even if it's by some of OCaml's bigger players! One could even imagine having things so that programs linked normally use a randomly seed hashtable and programs *linked* with -g use a fixed seed, for debugging (i.e. the current behaviour) - again, with suitable documentation explaining why you don't put debug builds of software on live web servers... David