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 <[email protected]> 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
