On 8/25/20 10:11 PM, Kim Barrett wrote:
Finally getting back to this after some internal discussion that dragged along because folks have been busy.
On Apr 8, 2020, at 12:05 PM, Gil Tene <gil@azul.com> wrote:
Lifting out of response from the JIRA issue:
I always worry when proposing a change to an existing invariant, and PhantomReference currently carries the stated and specified behavior of "the referent of a phantom reference is always inaccessible".
I can imagine quite a few forms of gaining new information I do not otherwise have access to by using PhantomReference::RefersTo if it allowed me to examine the current referent of a phantom reference and test to see if it is (a) null or (b) a specific object I have a reference to. Both of those would provide me with information that is impossible for me to get according to current specifications. With that newly available information one can come up with all sorts of nice things to do... Think in terms of "side-channel" as an example of the sort of thinking black hats can apply to this new knowledge, but the potential attacks are not limited to side-channels.
While it will be "obviously safe" to have Reference:RefersTo(obj) provide the same information that (Reference.get() == obj) would, providing more information than that would be a change to the specified behavior of Reference types, which we should be extra paranoid about. Since PhantomReference::get returns null by definition, we should remain consistent with that in PhantomReference::refersTo [copied from JIRA issue] That all assumes that I'm giving you access to my phantom references. But if I'm doing that then I've got much worse problems than any potential information leakage of the kind being suggested. If you have one of my phantom references then you can enqueue it, triggering any associated cleanup while I'm still using the referent. One should not give one's phantom references to untrusted code. That's nothing new, and is not made any worse by having Reference.refersTo work the same way for phantom references as for other reference types.
Agree. We should probably document this in the Java security code guideline to advice the developers be cautious and not to leak Reference objects. Mandy