Comment by tptacek | Hacker News Reader

Comment by tptacek | Hacker News Reader

Reading this, you'd think getaddrinfo() was the first glibc vulnerability ever discovered. "Look at how many things are affected! Even sudo! How will we ever detect them all?" Let's hope the author has some benzos on hand before they learn about kernel vulnerabilities.

Look: not only is this flaw not unprecedented, like, at all, but just last year we had a glibc vulnerability in gethostbyname() --- the most common libc DNS resolution function. You may remember the flaw by its brand name, "GHOST".

GHOST did not ruin the Internet or justify what I can best describe as 4000 words of concerned back-patting. And it was exploitable on day one!

Just patch the stupid thing, like everything else, and get on with your life.

I do object strongly to the bit at the end, about how ASLR, NX, CFG, &c are effective only at showing us who the best exploit developers are. Horse. Shit. There are today memory corruption bugs that are not exploitable because of runtime constraints. Moreover, when Linux and OS X bugs turn out to be widely and reliably exploitable, the reason tends to be that they hit something that isn't fully covered by runtime protections.

If you want to argue that critical, exposed network services shouldn't be written in C in 2016, you'll get no argument from me, or, for that matter, 98% of Hacker News. We should definitely get moving on porting stuff like DNS servers to things like Go and Rust.

> If you want to argue that critical, exposed network services shouldn't be written in C in 2016, you'll get no argument from me, or, for that matter, 98% of Hacker News.

Not 98% of Hacker News. There are an awful lot of people who think modern C++ is memory safe.

C++ isn't 'memory safe', but what it does is give you the ability to write memory and resource safe types, and then lean on the type system as a means of ensuring memory safety.

C doesn't let you do that. It's just incapable, and it's a handicap that leads to bad APIs and bad client code. Take gethostbyname() as a historical example. It returns a pointer to static data, which avoids memory leaks at the cost of being thread-unsafe. Want a fix? use gethostbyname_r()... ok, great, except now you're dealing with a function with six parameters and have even more ways to shoot yourself in the foot. Ok well, they're both deprecated anyway... use getaddrinfo()... just don't forget to use freeaddrinfo() because this function allocates a linked list. So don't forget to check for null pointers as you enumerate it. C++ brings value semantics, iterators, and RAII to table and these problems largely go away.

All this is why C++ is better than C. In C++ you can have memory safety, thread safety, type safety, and a simple API. It's not perfect, and it's not easy, designing APIs never is, but at least it's a remote possibility.

> C++ isn't 'memory safe', but what it does is give you the ability to write memory and resource safe types, and then lean on the type system as a means of ensuring memory safety.

No, it doesn't, because it isn't memory safe.

> All this is why C++ is better than C. In C++ you can have memory safety, thread safety, type safety, and a simple API.

No, you can't. C++ is not memory safe. Use after free happens in C++ all the time, because smart pointers do not protect you from dangling pointers and null pointer dereference, among other things.

Instead of copy and pasting examples to show this, I'll just link to other posts of mine from the past two months: https://news.ycombinator.com/item?id=11111987, https://news.ycombinator.com/item?id=11054630, https://news.ycombinator.com/item?id=11055020, https://news.ycombinator.com/item?id=10819501.

Move your for-loop in to an algorithm that takes Container by const& and your resize() / iterator invalidation problem becomes a compile error. If you actually need to resize your array while you iterate, then a language like Rust is going to catch your pointer invalidation, but it's not going to make the impossible possible and suddenly make your algorithm do something sensible.

I never claimed C++ statically enforced memory safety. Clearly that can't happen while its a superset of C. I just claim that it's steadily reaching the point where the most concise and elegant code with the best API is the safest.

And I'd argue that's the problem with C. The language is too weak to write safe code concisely, so you end up with too much cognitive load, get lazy, and then end up with sprawling unauditable messes like we see in glibc lately.

I've updated the post with further details.

Reply on news.ycombinator.com