[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug classpath/25727] New: Hashtable is not secure
From: |
subanark at gmail dot com |
Subject: |
[Bug classpath/25727] New: Hashtable is not secure |
Date: |
9 Jan 2006 16:48:59 -0000 |
It might be a secret, but Sun's implementation of Hashtable will ask the
currently existing key in a Hashtable if it is equal to the queried key instead
of the otherway around. Anyone who knows this secret can depend on using a
backing hashtable to allow public and private values without worring about evil
code accessing the private values. This can be seen in
JComponent.getClientObject, where I assume values are put there that Sun does
not want unsecure code access to.
I think the Hotspot can probably better optmise a HashMap since the same equals
method will get run over and over, which is why this secure feature would only
be in Hashtable.
Code example:
import java.util.HashMap;
import java.util.Hashtable;
import java.util.Map;
public class HashMapVTable {
public static void main(String[] args)
{
HashMap<SecureKey,Object> hashMap = new
HashMap<SecureKey,Object>();
testMap(hashMap,"HashMap");
Hashtable<SecureKey,Object> hashtable = new
Hashtable<SecureKey,Object>();
testMap(hashtable,"Hashtable");
}
public static void testMap(Map<SecureKey,Object> map,String name)
{
SecureKey secureKey = new SecureKey("MyKey");
Object data = new Object();
map.put(secureKey,data);
FakeKey fakeKey = new FakeKey("MyKey");
boolean gotData = map.get(fakeKey) == data;
if(gotData)
System.out.println(name+" is vulnerable");
else
System.out.println(name+" is not vulnerable");
}
private static class SecureKey
{
private String name;
public SecureKey(String name)
{
this.name = name;
}
@Override
public int hashCode() {
return name.hashCode();
}
@Override
public boolean equals(Object obj) {
return obj == this;
}
public String getName()
{
return name;
}
}
private static class FakeKey
{
private String name;
public FakeKey(String name)
{
this.name = name;
}
@Override
public int hashCode() {
return name.hashCode();
}
@Override
public boolean equals(Object obj) {
return obj instanceof SecureKey &&
name.equals(((SecureKey)obj).getName());
}
}
}
The output is:
Sun:
HashMap is vulnerable
Hashtable is not vulnerable
ClassPath:
HashMap is vulnerable
Hashtable is vulnerable
--
Summary: Hashtable is not secure
Product: classpath
Version: 0.19
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: classpath
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: subanark at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25727
- [Bug classpath/25727] New: Hashtable is not secure,
subanark at gmail dot com <=
- [Bug classpath/25727] Hashtable is not secure, pinskia at gcc dot gnu dot org, 2006/01/09
- [Bug classpath/25727] Hashtable is not secure, subanark at gmail dot com, 2006/01/09
- [Bug classpath/25727] Hashtable is not secure, jeroen at frijters dot net, 2006/01/10
- [Bug classpath/25727] Hashtable is not secure, jeroen at frijters dot net, 2006/01/10
- [Bug classpath/25727] Hashtable is not secure, cvs-commit at developer dot classpath dot org, 2006/01/10
- [Bug classpath/25727] Hashtable is not secure, pinskia at gcc dot gnu dot org, 2006/01/28