Out-of-bounds read and write in the glibc's qsort()

Re:Out-of-bounds read and write in the glibc's qsort() by sgift on Monday February 05, 2024 @01:51PM (#39265231)

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.

[ Parent | on HN ]

Re:Out-of-bounds read and write in the glibc's qsort() by hedora on Monday February 05, 2024 @02:35PM (#39265917)

It 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.

[ Parent | on HN ]