Folks,
In a recent phone conversation with Dan Scales, I presented an argument
for "initialization safety" which Dan encouraged me to share with the list.
Simply put, the argument is that the lack of initialization safety may
be exploited by an attacker to compromise the security of a library that
takes immutable objects on input.
Suppose a library takes a String on input; the library has every right
to assume that the String will not change. Thus, it's not at all uncommon
for a library to check a String argument for validity once, and then use it
indefinitely with no further checks. If the String changes, security is
compromised. This is not a purely hypothetical situation; a release was
recently delayed because a serialization problem allowed an attacker to
change a String. A demonstration applet exploited the hole to communicate
with an arbitrary host!
So what does this have to do with initialization safety? Consider a
program with two threads. The first thread (the "producer") creates strings
repeatedly and "publishes" them to a static String array. The second thread
(the "consumer") reads each String reference out of the array and passes it
on to a system library. Neither thread does any synchronization at all.
Once in a blue moon (assuming a sufficiently weak memory model) the threads
will "get lucky", and the second thread will pass a reference to an
improperly initialized String to the system library. The value of this
String can change when the second thread finally sees the correct values of
the memory locations corresponding to the string.
Thus, the weak memory model can be exploited by an attacker to corrupt a
class that expects reasonable behavior from its immutable input arguments.
Simply put, it is not uncommon for one class to depend on the guaranteed
behavior of another class (e.g., the immutability of a String) for its
security. That is why I think it's absolutely intolerable to allow
ill-formed objects to be visible to a thread, even if the thread does not
perform adequate synchronization.
Josh
-------------------------------
This is the JavaMemoryModel mailing list, managed by Majordomo 1.94.4.
To send a message to the list, email JavaMemoryModel@cs.umd.edu
To send a request to the list, email majordomo@cs.umd.edu and put
your request in the body of the message (use the request "help" for help).
For more information, visit http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:17 EDT