[Esapi-user] ESAPI Random Number Generation Broken

Kevin W. Wall kevin.w.wall at gmail.com
Mon Apr 7 04:26:20 UTC 2014


Periodic seeding, unless you have a HWRNG source *that you trust* (many
do not trust the Intel random instruction, RdRand), you are just shuffling
the deck chairs around on the Titanic so to speak.

Where to you get the randomness to reseed from? (Keep in mind that you should
have at least 160-bits of true randomness for SHA1PRNG.) From /dev/urandom?
Well, there are many cryptographers that don't trust that, especially
if you are on
a VM. /dev/urandom has an entropy pool of sorts, but it can be consumed by a
malicious process running on the same host excessively requesting it
(or on a VM,
but YMMV then; not as straight-forward). How about from /dev/random? Well, that
blocks if there is not sufficient entropy available. You request 20
bytes and there are
only 10 bytes in the pool, your read system call blocks. That can lead
to an intentional
DoS by a local malicious process.  (Plus, there are times, especially at system
start up where blocking is quite common. At my previous job, we had a
EntropyPool
class that had different security levels and at the highest one, it
read from /dev/random
and blocked. We had one Java application requesting 4096 bits to create crypto
keying material and there was one time after a reboot that they found that Java
process blocked for TWENTY minutes on a server! 20 minutes!)

So there is no simple solution that works for all situations.

Still, there should NEVER be a problem generating anywhere near only 20k
32-byte random strings using a SHA1PRNG without reseeding SecureRandom.

-kevin

On Mon, Apr 7, 2014 at 12:10 AM, Jim Manico <jim.manico at owasp.org> wrote:
> Supposedly, the only reason you need to reseed is because an attacker who
> can see many random values from the same SecureRandom instance has an
> increasingly better chance to determine the seed. Once the attacker can
> determine the seed, the attacker can determine the PRNG sequence.
>
> However, this does not explain why Rook reported that 20,000 calls to the
> same instance ESAPI's Randomizer popped up as deterministic in the Burp
> analysis tool.
>
> However, *periodic* reseeding like you suggest seems more than appropriate,
> regardless of what our code archeology discovers. :)
>
> More soon.
>
> - Jim
>
>
>
> On 4/6/14, 8:40 PM, John Melton wrote:
>
> The javadoc says it's threadsafe, to a fault (performance).
>
> According to
> http://www.cigital.com/justice-league-blog/2009/08/14/proper-use-of-javas-securerandom/
> , the same instance shouldn't be used forever. You can either periodically
> re-seed, or periodically throw away the instance and re-instantiate.
> Probably reasonable to reset the secure random every 50/100/500 calls (maybe
> another config option - oh joy!)
>
>
> On Sun, Apr 6, 2014 at 11:23 PM, Jim Manico <jim.manico at owasp.org> wrote:
>>
>> The problem is not thread safety, the original report had basic code that
>> just returned 20,000 values from the ESAPI Randomizer API using the default
>> configuration (SHA1PRNG) which came out non-random according to Burp's
>> analyzer at the time.
>>
>> Several of my clients at the time acknowledged the same problem with
>> ESAPI-Java and also used burp for analysis. We "fixed" it by just using new
>> SecureRandom instances for CSRF tokens and other random number needs. I
>> believe most of the ESAPI crypto API is using it's own internal SecureRandom
>> instances.
>>
>> Perhaps the problem is Burp's random analyzer?
>>
>>  -Jim
>>
>>
>>
>> On 4/6/14, 8:11 PM, Jeff Williams wrote:
>>>
>>> Checked into SecureRandom and it appears to be thread safe.  It's even
>>> documented in Java7.
>>>
>>> The nextInt issue is just a javadoc problem. Should say "exclusive" like
>>> the underlying nextInt call
>>>
>>> --Jeff
>>>
>>>
>>>
>>>> On Apr 6, 2014, at 11:03 PM, "Jim Manico" <jim.manico at owasp.org> wrote:
>>>>
>>>> Jeff,
>>>>
>>>> I had a phone call with Kevin this evening and we are not sure if the
>>>> problem is the single instance of SecureRandom, or perhaps some problem from
>>>> the encoding, or maybe an OS level issue (since SecureRandom has different
>>>> behavior [even with the same algorithm and seed] on different JVM's/OS's),
>>>> or some other error that we have not figured out yet.  Also check out the
>>>> related bug https://code.google.com/p/owasp-esapi-java/issues/detail?id=217
>>>> which seems rather glaring (same value returned every time) we will
>>>> investigate this as well.
>>>>
>>>> The test case is simple - use ESAPI to generate a sequence of random
>>>> values and run it through a well vetted random number analyzer, but we'll
>>>> provide specific code for this soon.
>>>>
>>>> David Rook provided the initial analysis and used Burp's random number
>>>> analyzer. The bug is entered here
>>>> https://code.google.com/p/owasp-esapi-java/issues/detail?id=323 and we will
>>>> track our progress there. Kevin and I intend of find and fix the problem
>>>> ASAP.
>>>>
>>>> More soon,
>>>> Jim
>>>>
>>>>
>>>>> On 4/6/14, 7:45 PM, Jeff Williams wrote:
>>>>> Could you share the test case please?   Are you suggesting that it is
>>>>> not safe to use a single instance of SecureRandom?
>>>>>     Does the test rely on the nextInt( a, b ) call?  I think the
>>>>> Javadoc for that method is broken and  should say the max is *exclusive* --
>>>>> mirroring the behavior of the Java random.nextInt( x ) call.
>>>>>
>>>>> --Jeff
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: esapi-user-bounces at lists.owasp.org
>>>>> [mailto:esapi-user-bounces at lists.owasp.org] On Behalf Of Jim Manico
>>>>> Sent: Sunday, April 06, 2014 6:54 PM
>>>>> To: esapi-dev at lists.owasp.org; esapi-user at lists.owasp.org
>>>>> Subject: [Esapi-user] ESAPI Random Number Generation Broken
>>>>>
>>>>> Folks,
>>>>>
>>>>> Over a year ago the ESAPI team got a report from David Rook that the
>>>>> ESAPI Random Number Generator was not providing a random sequence of values.
>>>>> Using burp's random number analyzer, he found that ESAPI was providing a
>>>>> very predictable sequence of numbers from the
>>>>> https://code.google.com/p/owasp-esapi-java/source/browse/branches/2.1/src/main/java/org/owasp/esapi/reference/DefaultRandomizer.java
>>>>> class. I was asked not to report on this to give the team time to fix
>>>>> it, but it's been over a year or more. So I reported it officially today.
>>>>> https://code.google.com/p/owasp-esapi-java/issues/detail?id=323
>>>>>
>>>>> I believe this also may be the cause of
>>>>> https://code.google.com/p/owasp-esapi-java/issues/detail?id=217
>>>>>
>>>>> This also impacts anyone using ESAPI for Java for CSRF protection. Your
>>>>> CSRF tokens are not true random, they are a predictable sequence of numbers
>>>>> that will make it easier for an attacker to guess your CSRF token value.
>>>>> This also impacts key creation in the crypto API's. This also impact the
>>>>> random access map in ESAPI.
>>>>>
>>>>> A quick fix is to fork
>>>>>
>>>>> https://code.google.com/p/owasp-esapi-java/source/browse/branches/2.1/src/main/java/org/owasp/esapi/reference/DefaultRandomizer.java
>>>>> class and create a new instance of SecureRandom for each use. Be sure
>>>>> to test the performance impact of this.
>>>>>
>>>>> Any questions, drop me a line here or at jim.manico at owasp.org.
>>>>>
>>>>> Regards,
>>>>> Jim
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Esapi-user mailing list
>>>>> Esapi-user at lists.owasp.org
>>>>> https://lists.owasp.org/mailman/listinfo/esapi-user
>>
>>
>> _______________________________________________
>> Esapi-user mailing list
>> Esapi-user at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/esapi-user
>
>
>
>
> _______________________________________________
> Esapi-user mailing list
> Esapi-user at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-user
>



-- 
Blog: http://off-the-wall-security.blogspot.com/
NSA: All your crypto bit are belong to us.


More information about the Esapi-user mailing list