caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Gerd Stolpmann" <info@gerd-stolpmann.de>
To: "Philippe Veber" <philippe.veber@gmail.com>
Cc: "Paolo Donadeo" <p.donadeo@gmail.com>,
	"OCaml mailing list" <caml-list@inria.fr>
Subject: Re: [Caml-list] Re: [oss-security] CVE request: Hash DoS vulnerability (ocert-2011-003)
Date: Tue, 13 Mar 2012 14:23:15 +0100	[thread overview]
Message-ID: <4ec32a156daa6211ca4d465c9a7b8745.squirrel@gps.dynxs.de> (raw)
In-Reply-To: <CAOOOohQbc1i17tdytamPh5bbW=FNZC2dJSCyyz7vxkf8seB74Q@mail.gmail.com>


> 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 <p.donadeo@gmail.com>
>
>> 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 <bardou@lsv.ens-cachan.fr>
>> 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.



  reply	other threads:[~2012-03-13 13:23 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
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 [this message]
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=4ec32a156daa6211ca4d465c9a7b8745.squirrel@gps.dynxs.de \
    --to=info@gerd-stolpmann.de \
    --cc=caml-list@inria.fr \
    --cc=p.donadeo@gmail.com \
    --cc=philippe.veber@gmail.com \
    /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).