harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [drlvm][kernel_classes] ThreadLocal vulnerability
Date Mon, 20 Nov 2006 21:44:32 GMT
Regression test and fix for DRLVM kernel classes committed in r477355.

Weldon: Are you maintaining the classlibadapter code?  Can you fix that too?

Regards,
Tim

Thomas Hawtin wrote:
> I had a quick browse through the Harmony SVN and spotted what appears to
> be a vulnerability in the java.lang.ThreadLocal implementation. I have
> briefly discussed this with Tim Ellison and Geir Magnusson Jr., off list
> before posting here.
> 
> Harmony uses a per Thread HashMap (WeakHashMap in classlibadapter) to
> map ThreadLocals onto values. HashMaps (should) check for equality with
> Object.equals and Object.hashCode instead of == and
> System.identityHashCode.
> 
> Malicious subclasses of ThreadLocal can override hashCode to run through
> all possible hash codes, extracting all the ThreadLocals present in the
> current thread through an overridden equals. Some of these ThreadLocals
> may contain sensitive values. Even if Harmony generates identity hash
> codes entirely at random, the process should be completable in the order
> of a few minutes of CPU time.
> 
> Tim Ellison suggests replacing the HashMap with an IdentityHashMap. I
> agree that this would fix the security vulnerability. Some modern code,
> such as I believe Spring, creates many ThreadLocal instances, so you may
> wish to look further at quality of implementation issues.
> 
> FWIW, I believe early versions of Sun's 1.3 J2SE suffered a similar
> problem.
> 
> Tom Hawtin
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

Mime
View raw message