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
