caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Romain Bardou <bardou@lsv.ens-cachan.fr>
To: caml-list@inria.fr
Subject: Re: [Caml-list] Re: [oss-security] CVE request: Hash DoS vulnerability (ocert-2011-003)
Date: Tue, 13 Mar 2012 16:39:48 +0100	[thread overview]
Message-ID: <4F5F6A44.2070601@lsv.ens-cachan.fr> (raw)
In-Reply-To: <4ec32a156daa6211ca4d465c9a7b8745.squirrel@gps.dynxs.de>

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".

That being said I don't really care that much, I'm just thinking out 
loud here :p

Cheers,

-- 
Romain Bardou

  reply	other threads:[~2012-03-13 15:40 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
2012-03-13 15:39                 ` Romain Bardou [this message]
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=4F5F6A44.2070601@lsv.ens-cachan.fr \
    --to=bardou@lsv.ens-cachan.fr \
    --cc=caml-list@inria.fr \
    /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).