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: [oss-security] 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

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