Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 13 Jun 2013 02:56:34 +0400
From: Solar Designer <>
Subject: Re: CVE request: WordPress 3.5.1 denial of service vulnerability

On Thu, Jun 13, 2013 at 12:05:14AM +0400, Alexander Cherepanov wrote:
> On 2013-06-12 17:11, Solar Designer wrote:
> >Arguably, library code should reject the most insane parameter values.
> >For example, musl libc - - version 0.9.10
> >rejects bcrypt's log2(cost)>  19 and limits SHA-crypt's rounds count
> >to<  10M for this reason (original SHA-crypt limits to<  1 billion).
> On a related note: shouldn't John the Ripper also reject hashes with 
> insane run-time or memory cost parameters?

I don't have strong feelings one way or the other, which is why I
haven't implemented this so far.  Also, in JtR we did not support any
hashes/ciphers with configurable memory cost until very recently, so
that part of the issue did not arise.  As to processing time cost, in
JtR it's at worst a DoS against a cracking run, which the user would
notice and hopefully deal with.  Yes, having some warnings printed could
help pinpoint the culprit hashes - we can add that.  As to the memory
usage issue, maybe we need to have a configurable total memory limit (in
john.conf) - not a per-hash limit.  We could use RLIMIT_AS (or the like)
where supported.  It's more reliable than doing our own memory usage
tracking, although then we'd need to ensure we're able to print a
sensible error message when that limit is almost reached (this is not
difficult, it's just something not to overlook).


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.