Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <455D9A52.2020407@tackline.plus.com>
Date: Fri, 17 Nov 2006 11:17:38 +0000
From: Thomas Hawtin <tackline@tackline.plus.com>
User-Agent: Thunderbird 1.5.0.4 (X11/20060602)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: [drlvm][kernel_classes] ThreadLocal vulnerability
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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