Recent Java Sandbox escapes

[Alkanor Oumbratok]

Hello people,

I am kind of new to this kind of mailing list, so do not hesitate to
indicate to me if I have any inappropriate behavior (even if I hope it
should not be the case).

I recently came upon Java and Java security related aspects, mostly around
the SecurityManager and what orbits around.
To be precise, I am currently analysing old exploits against the Java
sandbox, and trying to understand how freshly discovered exploits within
the Java core libraries could be implemented. A logic thought made me
search for recently applied patches for high severity CVSS targeting the
Java core libraries.
So, I came to the CVE CVE-2020-2803 and CVE-2020-2805. However, when
observing the two associated patches, I wonder if these are really
exploitable, and more generally, who and what is the process which decides
the CVSS score of this kind of vulnerability.

I explain myself : on the patch for CVE-2020-2803, one can see the position
and limit variables are not relatively checked when creating a new *Buffer
within the "slice" method. This indeed leads to a potentially undefined
behavior. However, the only objects on which this can have an impact are,
correctly if I am wrong, the associated native java arrays (like the double
hb[] array for HeapDoubleBuffer).
And there is no chance any dangerous effect comes from there, as an
OutOfBoundException will be raised if any bound is wrong at the end.
It would have been different if the same principle can be applied to
Direct*Buffer, as these seem to have more impact on raw memory. However,
these buffers are not vulnerable in their splice method due to the checks
being performed.
Am I right for this one ?

Concerning the CVE-2020-2805, I must admit I am less confident of what I
say regarding the previous one. For me, the patch gives the impression to
force a certain MethodType to be in cache instead of "letting" the rtype
and ptypes variables possibly being externally modified before readResolve
is called (leading to the potential mentioned impact).
However, I don't see any way of how these attributes could be modified
between the call to ReadObject and the following call to ReadResolve, which
should be performed immediately after.

I may be wrong on both points, and I would be really grateful if someone
could explain why these 2 CVE have been rated this high whereas at first
glance there isn't any really exploitable related scenario.

Regards,
--
Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20200819/9c441b35/attachment.htm>