Re: CVE request: WordPress 3.5.1 denial of service vulnerability

[Solar Designer <solar () openwall com>]

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 - http://www.musl-libc.org - 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).

Alexander