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 q2DDNObw023930 for ; Tue, 13 Mar 2012 14:23:25 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8FABVKX0/U4xEJk2dsb2JhbABDpBKRSiIBAQEBCQkUFAMkggkBAQQBbgsFCwUGGA0hISQSBhMJCAGHcwkHvH6JQocjBI1QF5MUh14 X-IronPort-AV: E=Sophos;i="4.73,575,1325458800"; d="scan'208";a="135818522" Received: from moutng.kundenserver.de ([212.227.17.9]) by mail4-smtp-sop.national.inria.fr with ESMTP; 13 Mar 2012 14:23:19 +0100 Received: from office1.lan.sumadev.de (dslb-094-219-210-049.pools.arcor-ip.net [94.219.210.49]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MCx2B-1SFSBb0QmR-009MLC; Tue, 13 Mar 2012 14:23:18 +0100 Received: from gps.dynxs.de (localhost [127.0.0.1]) by office1.lan.sumadev.de (Postfix) with ESMTP id 57456C00CB; Tue, 13 Mar 2012 14:23:15 +0100 (CET) Received: from 178.4.234.241 (SquirrelMail authenticated user gerd) by gps.dynxs.de with HTTP; Tue, 13 Mar 2012 14:23:15 +0100 Message-ID: <4ec32a156daa6211ca4d465c9a7b8745.squirrel@gps.dynxs.de> In-Reply-To: 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> Date: Tue, 13 Mar 2012 14:23:15 +0100 From: "Gerd Stolpmann" To: "Philippe Veber" Cc: "Paolo Donadeo" , "OCaml mailing list" 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:zkQHRCn4DuDAr7MDAIS4IlPvJAPB2eDnVipLgv4+Ooz dtqpy775vVFdPF+0v2RMXRNXZ7lmUW6QHYpshJLPww4Z3jgxyK lSEoMz6QAkh48gO9AAsRcT9+bLp2vKFew9qVM1EPtRD2FyNXxw pu0ZywF4+Hy2uc/RZUrTBtTxX/PDrRkR5wiq8mBEdabSV/XaLS 9b2O5CcXpOa8PfLa9itQwiQ2BbfmLX2/5L0YyiyT0gx+xTqzyM VzYEf4cEHcDO98xSxKJTS9uMdAAYuv4Bwng3SOjdTKA9EFnex2 CGKAwlc+mKQof90Bt9Oro0ykDARZK5uJDoo+ewP4B77xvppJKg GzzGXVYTrWZxkIefMKkkw/fcPz9JAbx8Da+yqdHGPf+oD0PEzl IrBEp87qAyZTj9VJuw73desLPx48ZUBqK8= Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id q2DDNObw023930 Subject: Re: [Caml-list] Re: [oss-security] CVE request: Hash DoS vulnerability (ocert-2011-003) > 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). > Having a default randomisation seems much too intrusive to me > (notwithstanding the importance of web programming for ocaml's future ;o)) Btw, it's not just web programming. This is only the original example, and it works because there is a message type for web protocols with unlimited length. Most other network protocols don't have this, and are immune. The other big class of attackable programs are offline processors of untrusted data. It's of course harder to do, and you would probably need some other information leak to conduct it, but these programs are not outside the danger zone just because they are not directly accessible. > and for those changes that modify the semantic of a program, you have to > be > in control. So I second Paolo's opinion. Reproducibility is definitely an important feature. Gerd > However, assuming ocaml users will be "aware of attacks", at least more > than users of other languages, is not only controversial but also non > relevant: there are beginners in ocaml too (who may also be beginners in > programming), and these should be taken care of. A small note in the doc > on > the DOS vulnerability that may arise from the use of Hashtbl in a web > application context is enough to protect the users I think, and is of > interest for the casual Hashtbl reader. This note could appear in a > different font/color than the main description of [Hashtbl.create], to > preserve the readability of the docs. > > my 2 cent > ph. > > 2012/3/13 Paolo Donadeo > >> In my humble opinion, here we have two different vision of what >> computer programming is, or should be. Your statement "maybe it's >> better to assume that the programmer will not be aware of attacks" may >> be true for the average Java programmer (please, no flame, no insult >> intended to Java programmers reading this list!) but not for an OCaml >> programmer. I want to be perfectly aware of attacks, and I want to be >> in control of the data structure I use, and not "be unaware"... >> >> In Python, the other language I use every day, dictionaries are >> implemented as hash tables and not having reproducibility is a PITA. >> >> >> -- >> Paolo >> >> >> On Tue, Mar 13, 2012 at 10:54, Romain Bardou >> wrote: >> > Hi, >> > >> > >> >> 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. >> > >> > >> > FWIW, as a developer I do not expect reproducibility from Hash tables >> (nor >> > from the Random module actually) but I do expect some way to control >> > reproducibility (i.e. read the current seed, give my own seed). Maybe >> it's >> > better to assume that the programmer will not be aware of attacks, and >> > provide him with a safer environment. >> > >> > On the other hand, when you find a bug and need reproducibility, it's >> too >> > late if you have used a random seed without recording it. And could it >> break >> > some existing applications? >> > >> > I guess you('re) already had(having) this discussion though. >> > >> > Cheers, >> > >> > -- >> > Romain >> >> >> -- >> 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 >> >> > > -- > 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.