[concurrency-interest] ThreadLocalRandom clinit troubles

Stanimir Simeonoff stanimir at riflexo.com
Thu Jun 19 04:14:30 EDT 2014


 The problem is that java.security.SecureRandom may need custom security
providers that in effect are not prevented from touching TLR.
The code in clinit should not be able load unknown classes.

Stanimir


On Thu, Jun 19, 2014 at 11:02 AM, Peter Levart <peter.levart at gmail.com>
wrote:

>  On 06/19/2014 08:32 AM, Stanimir Simeonoff wrote:
>
> I wonder why just don't use the /dev/random if available on *nix -
> implemented by sun.security.provider.NativePRNG or
> sun.security.mscapi.PRNG() on Windows that calls CryptGenRandom.
> Both support SecureRandomSpi.engineGenerateSeed(int) that provides an
> arbitrary amount of entropy.
> Although the approach would cause some more classes to load, no arbitrary
> providers should be initialized.
>
>
> I think this is waht you get when you set "java.util.secureRandomSeed"
> system property to "true". TLR uses java.security.SecureRandom.getSeed(8)
> in this case.
>
> Regards, Peter
>
>
>
> Stanimir
>
>
>
> On Thu, Jun 19, 2014 at 7:25 AM, Martin Buchholz <martinrb at google.com> <martinrb at google.com>
> wrote:
>
>
>  ThreadLocalRandom's clinit method creates an intermediate broken state of
> ThreadLocalRandom and then proceeds to run some networking code to get some
> more machine-specific entropy in initialSeed().  This will fail if the
> networking code ever recursively uses a (not yet functional)
> ThreadLocalRandom.  The clinit for InetAddress can cause arbitrary code to
> be run,
>
> at
> java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:354)
> at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:393)
>  at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474)
> at java.net.InetAddress$3.run(InetAddress.java:923)
>  at java.net.InetAddress$3.run(InetAddress.java:918)
> at java.security.AccessController.doPrivileged(Native Method)
>  at java.net.InetAddress.createNSProvider(InetAddress.java:917)
> at java.net.InetAddress.<clinit>(InetAddress.java:962)
>
> if the sun.net.spi.nameservice.provider system property is defined.
>
> The current strategy of ThreadLocalRandom relying on other java code for
> initialization seems risky.  Safer would be to have native code provide
> some entropy at program startup for use by ThreadLocalRandom.  I don't have
> a clean solution for this problem (other than to rip out initialSeed()).
>  Strictly more reliable would be to mix in the entropy from the system at
> the end of ThreadLocalRandom's clinit instead of the beginning, but the
> basic problem remains.
>
> _______________________________________________
> Concurrency-interest mailing listConcurrency-interest at cs.oswego.eduhttp://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
> _______________________________________________
> Concurrency-interest mailing listConcurrency-interest at cs.oswego.eduhttp://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140619/f8e62113/attachment.html>


More information about the Concurrency-interest mailing list