RE: [Caml-list] Re: [oss-security] CVE request: Hash DoS vulnerability (ocert-2011-003)

[David Allsopp <dra-news@metastack.com>]

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