Hacker News Reader

Comment by goalieca | Hacker News Reader

That’s a pretty cool find. It just goes to show even some of the oldest and most widely used open source libraries still have security issues. This is a rare corner case but it’s still a fantastic find. I suppose no static analysis tools found it over all those years.

View on HN

It's not new. They are just passing in an invalid parameter. If you pass random parameters into a function like memcpy it will do bad stuff too.

C APIs were not all designed to be safe to call and can commonly crash or introduce a vulnerability.

I can imagine the future memcpy CVE: "arguments to memcpy to regions not previously allocated or after having been freed can potentially cause security issues. Therefore we propose that memcpy check its arguments against this new list of valid memory addresses that we are now going to keep around..."

So what I mean is: how much performance are we giving up with this "fix" for qsort?

the glibc qsort function is already something you only use if you don't care about performance.

Then what is a better alternative? I was always told that I shouldn't implement something as trivial as sorting algorithms by myself...

A simple solution is to create a C++ file and exposing sorting functions to C. E.g. "void sort_int(int *data, size_t n)". The implementation uses then std::sort.

Unfortunately, qsort is really slow and sometimes barely usable.

You were told correctly, but there is a lot of room between using the C standard library and making your own sort. C++ STL std::sort is one, but the internet is filled with libraries you can download, of course you can find a better alternative with a search.

ARM Morello does that check in hardware.

I've seen a few programs that misbehave due to a comparison function that doesn't have all of the necessary properties.

Maybe what's notable from a security perspective is that here's a contract about the behavior of an algorithm (comparison function) as opposed to the value of an argument (null pointer, negative, bigger than N, etc.).

Still qualifies as passing an invalid parameter.

This has always been an issue with sorting float arrays that contain NaN in C or C++ (e.g. with std::sort() with the default "<" comparator.)

what has been? OOB errors?

Seg faults

so... you're saying you've hit this exact bug before? I bet that was a fun debug session!

Reply on news.ycombinator.com