3 ms·
The reason I'd say assigning a CVE is the right call is that the "easy to misuse" leads to a potential security problem here because of the way glibc handles th
by sgift 3y ago
The reason I'd say assigning a CVE is the right call is that the "easy to misuse" leads to a potential security problem here because of the way glibc handles the function that you give it.
Case in point: You can make the same error in Java (I think it's even included in the docs for Comparators that you shouldn't do a-b, because of integer overflow/underflow), but it cannot lead to an out-of-bounds read/write. And that's because Java (~glibc) handles the comparison function that you give it differently.
- hedora 3y agoIt can't lead to an out of bounds write, but it could violate higher-level invariants in the Java program, and those could be exploitable. For instance, the bad comparator could be used in nested authentication checks: if check_A { drop privilege to FOO } else if check_B { drop privilege to BAR } else { /* leave root bit set, because "not (A or B)" means root */ } and it could lead to a privilege escalation in the face of malformed inputs. I've seen this sort of thing happen in the wild with Java.