Facebook Awards Researchers $100k For Detecting Emerging Class of C++ Bugs

An anonymous reader writes: Facebook has awarded $100,000 to a team of researchers from Georgia Tech University for their discovery of a new method for identifying "bad-casting" vulnerabilities that affect programs written in C++. "Type casting, which converts one type of an object to another, plays an essential role in enabling polymorphism in C++ because it allows a program to utilize certain general or specific implementations in the class hierarchies. However, if not correctly used, it may return unsafe and incorrectly casted values, leading to so-called bad-casting or type-confusion vulnerabilities," the researchers explained in their paper.

Re: Gee...

[Anonymous Coward]

Just change to ADA instead.

Re:

[0123456]

Just change to ADA instead.

Do the words 'unchecked conversion' mean anything to you?

Re:

[Phronesis]

Because no one ever cast int to pointer or vice versa in K&R C.

Re:

[Anonymous Coward]

Casting is much more common in C++ code. I don't know if that's because of the proliferation of unique types, or because there are more newbie programmers working in C++, but I cringe whenever I look at a large C++ code base.

Good C code rarely needs casting, if at all. I presume the same is true of C++.

When I need complex runtime polymorphism, I'll switch to a language that better handles that, like Lua. The nice thing about C is that it interoperates easily with almost all other languages. This is less tru

Re:

[maligor]

I think that was reported back in ... oh 1973 with the original C compiler.

Just another reason to avoid C++.

I don't think it's really a reason to avoid C++, you can do lots of perverse things in C also. It's a feature of the family.

The biggest problem I personally have with C++ is operator overloads, which I think are just a bad idea.

Re:

[0123456]

The biggest problem I personally have with C++ is operator overloads, which I think are just a bad idea.

Yeah, because having to remember when to use == and when to use .equals() and which order to put the arguments for foo.equals(bar) to avoid possible null pointer exceptions in Java is just so much less likely to introduce bugs.

Re:

[Keith Henson]

Even worse is when Bjarne Stroustrup changed the behavior of overriding equal. This comprehensively broke the last version of the Xanadu code I was involved with. After a couple of months of Roger Gregory--who is a very sharp programmer--failing to figure out what had happened, I had to single step the program (like debugging assembly code) to find what had gone wrong under the new compiler. Took most of a night.

Re:

[JesseMcDonald]

The biggest problem I personally have with C++ is operator overloads, which I think are just a bad idea.

The problem isn't so much operator overloads as it is C++-style overloading in general. Operators are just another kind of function. The problem with overloading them is that there is no common type signature or interface definition binding the various overloads together. That, and the limited set of available operators, which drives developers to reuse operator names for unrelated tasks. Even the STL sets a poor example by overloading bit-shift operators for I/O.

Contrast that with user-defined operators in

Re:

[lgw]

Operator overloads are there for the same reason void* is: when they actually make sense, they're a vast improvement. Complex numbers, for example, and really "+" is fine for string concatenation. Not being limited to built-in classes for that sort of thing is a feature, IMO.

C++ has few guiderails, and lets you write very unmaintainable code, much more so than C. But that's what let's you write performance-equivalent code that's much more maintainable than C.

My biggest gripe is coders who don't bother to

They've only just discovered this?

[Viol8]

Most casting errors will be caught at runtime. For the rest theres dynamic_cast though people tend to be too lazy to use it. Thats not a fault of the language.
Obviously if you use C style casts then you pays your money...

Re:

[Viol8]

That should have read "caught at compile time"

Re:

[Viol8]

I suggest you go read your C++ book again. It only returns null for pointers.

Re:

[Cassini2]

On error, dynamic_cast returns NULL for pointers, and an exception for references. From cppreference [cppreference.com]:

If the cast is successful, dynamic_cast returns a value of type new_type. If the cast fails and new_type is a pointer type, it returns a null pointer of that type. If the cast fails and new_type is a reference type, it throws an exception that matches a handler of type std::bad_cast.

Re:

[Anonymous Coward]

dynamic_cast requires RTTI, which means you're a bit optimistic to say "Most caught at compile time, for other casts use dynamic_cast".

Of course, templates mean that the compiler can substitute actual types. That gives you compile-time polymorphism instead of runtime polymorphism, and that in turn means you're increasingly right that most cast errors are caught at compile time. The price is unfortunately even longer compile times. Guess why I'm posting right now....

Yawn -- Another Closed Source Problem

[Anonymous Coward]

Thankfully, I only use FOSS software which is not vulnerable to this problem. Many eyes are sure to catch anything like this in the rigorous peer reviews that happen on every commit.

Re:

[Anonymous Coward]

We have applied CAVER to largescale software including Chrome and Firefox browsers, and discovered 11 previously unknown security vulnerabilities: nine in GNU libstdc++ and two in Firefox, all of which have been confirmed and subsequently fixed by vendors.

Re:

[jonkalb]

Thankfully, I only use FOSS software which is not vulnerable to this problem. Many eyes are sure to catch anything like this in the rigorous peer reviews that happen on every commit.

In case any readers are not seeing this statement as sarcasm, this award was given because the group found eleven previously unknown security vulnerabilities in open source code. Although "many eyes" are better than few eyes, is is naive to believe that open source code is flawless just because it is open source.

Re:

[Anonymous Coward]

Actually, it's more of a troll than sarcasm.

Re:

[Ed Tice]

Perhaps it is somewhat of a troll, but also makes a valid point. (I happen to like the sarcasm as well). We would like to think that all bugs are shallow given enough eyes. It's a reasonable mantra. And closed-source software has a history of eyes being intentionally closed (and the CSO getting mad at you for reporting bugs). Simple things like forgetting to close a file can be found through sheer determination. If the software is small enough for somebody to understand the whole thing, even the more

Rants against the C++ language

[Anonymous Coward]

And Stroustrup coming in 3.. 2.. 1..

No they haven't

[Burdell]

They haven't awarded anything to "Georgia Tech University", because there is no such thing. Georgia Tech is an institute; the Georgia Institute Of Technology.

Re:

[fnj]

I once saw a clueless idiot write "University of Boston" for "Boston University".

Perl doesn't have that problem!

[MagickalMyst]

Variable types are interpreted dynamically during runtime in Perl, depending on how the variable is called.

Sorry, I couldn't resist...

Debug runtime typing system

[Ed Tice]

I actually read the paper (okay, mod me down). Java and .Net have very strong runtime typing systems. C/C++ does not. Adding one is a bit tricky because there are certain things that are legal in C/C++ and not Java. Specifically, it's okay to cast between two classes that are non-polymorphic (unrelated from a type system perspective). Also C/C++ applications often have some additional performance requirements. They've created a runtime typing system and then a mechanism (probably a pre-processor) that can cause static_cast and dynamic_cast to instead use their casting mechanism. You turn it on for debug and off for release. We already have things like debug heaps to look for memory corruption at a small performance cost why not also have a debug type checking system. And, of course, since it gets switched off in production builds, it doesn't have the runtime performance costs. It's one of those things that is obvious as soon as somebody does it. Those are often some of the best advances as they can have a lot of impact quickly.

Re:

[friedmud]

Agreed... projects I work on have been doing this for ages. Here's one of the open source examples:

https://github.com/libMesh/lib... [github.com]

dynamic_cast with an error statement in DEBUG mode. static_cast otherwise (including if you don't have RTTI).

This is a no brainer...

Re:Debug runtime typing system

[Ed Tice]

From the paper: "Runtime type checking by dynamic_castis an expensive operation (e.g., 90 times slower than static_cast on average). For this reason, many performance critical applications like web browsers, Chrome and Firefox in particular, prohibit dynamic_cast in their code and libraries, and strictly use static_casto If can afford to use dynamic_cast in your code then, arguably, you can afford to write in a type-safe language like Java or C#. That's more of a philosophical discussion but the whole point is that if you can turn static_cast to dynamic_cast temporarily for debugging, that's useful. You an probably do that with some creative macro wizardry but this solution appears to be much better as it also includes an improved runtime type system

Re: Debug runtime typing system

[loufoque]

static_cast does not allow casting between unrelated pointer types, you need reinterpret_cast for that.
reinterpret_cast is known to be dangerous and is therefore avoided.
There is also the C-style cast, which is even more dangerous than reinterpret_cast.

Re:

[phantomfive]

Casting is a problem, true enough, but how do you exploit that? Is that a viable problem?

How about using a safer language?

[aaaaaaargh!]

If security is their concern, they could also use an inherently safer language like e.g. Ada instead. Just saying...

Basic fact flub in TFA

[Anonymous Coward]

Ain't no such animal as "Georgia Tech University." There is only Georgia Tech or the Georgia Institute of Technology, or the University of Georgia.

OMFG!

[jimpop]

1) learn something that older people learned decades ago

2) write document warning people, who ignored history..., of the dangers!!

3) profit!

Re:

[swillden]

1) learn something that older people learned decades ago

2) write document warning people, who ignored history..., of the dangers!!

3) profit!

They also built a tool to check potentially-dangerous casts. One we haven't had before.

Re:

[jimpop]

Many a tool builder has come along to build tools to overcome failures. Fuzzing, or whatever you call it, is just a poor man's method of finding errors (the real problem) in some code. Glorified greps.

Re:

[swillden]

Their tool isn't a fuzzer, it's a run-time cast checker -- to find the real error.

Re:OMFG!

[Ed Tice]

Fuzzing and grepping are entirely different things. If your original post hadn't gotten modded up, I probably wouldn't even respond. Fuzzing is a mechanism where cleverly malformed data is sent to an application or even a piece of hardware to see how it responds. Things like an invalid message with a proper authentication code. It's a pretty effective form of testing. In this context your comment might as well be. "Testing your software is just a poor man's method of finding errors (the real problem) in some code. Glorified greps." Ideally we aren't writing defects and are bug-free before a testing cycle, but that rarely (if ever) happens. Even if there are no verification defects there may be validation concerns. Both this and fuzzing are *dynamic* tools. Grep is a static tool although I don't know how it could possibly be employed in finding all but the most trivial defects. There are sophisticated static tools out there as well. (See FindBugs for an open source example of one). But these have nothing in common with grep.

Re:

[jimpop]

There is a vast difference between buggy code and poorly written code. The article and subject are about finding faults in poorly written code, which is something good programmers (and ones who are aware of a language's pitfalls and nuances) rarely produce. Testing is for finding bugs, rarely does testing involve analyzing code for purity.

Re:

[Ed Tice]

I realize that you want to believe this and I hate to be the one to burst your bubble so to speak but the fact is that these types of defects exist in almost any non-trivial piece of software. However, rather than go back and forth, how about you offer up some code that you've written and we'll run some of the tools you so dislike. If your code comes out "clean," I'll concede the point. But I'm confident that won't happen. In any event these tools are still not glorified grep and it's not information th

Re:

[jimpop]

I believe you are misconstruing what I've been saying. Tools are great, but they are no replacement for good solid code. Complex systems, or not, shouldn't contain the coding errors (they aren't bugs) that this and other fuzzing tools do find. Having, and awarding for such tools, leads, I believe, to an ecosystem of acceptability for poor coding. The correct avenue is to audit code and correct bad habits....but that takes deep knowledge of C/C++.

Re:

[Ed Tice]

You keep saying things like "This and other fuzzing tools" even though it's been pointed out in this thread numerous times that the tool in the paper is not a fuzzing tool and it isn't even close. This tool is finding bugs, not coding errors. It's finding a situation where one object type is cast to another but at some point that cast has become incompatible but the compiler can't catch it. If the compiler can't catch it, it's unlikely that a human audit is going to do so. You would have to continuously

Re:

[jimpop]

> You need to know the application domain and all parts of it.

I agree with that, 100%! I'm not doubting some of your statements, but you seem to be missing my main point. Forget fuzzing, type casting, tool sets, etc., I'm just arguing for purity in code as a better long term solution than post-processing object code.

A minor correction.

[Kickasso]

plays an essential role in misusing polymorphism in C++

Here, FTFY. Kids, if you cast, you are doing polymorphism wrong.

Re: A minor correction.

[loufoque]

Unless you're doing CRTP.

Re:

[Kickasso]

Even with CRTP it's avoidable, for the price of slightly increased verbosity.

Re:

[loufoque]

It's not avoidable unless you're limiting yourself to a subset of CRTP.

Re:

[Viol8]

Seriously? So you never cast a child class to a parent pointer? I don't think you do polymorphism at all.

Re:

[Kickasso]

Why would anyone want to? Cast is an explicit type conversion (see the standard, 5.4 [expr.cast]).

Re:

[Viol8]

*boggle*

Don't worry about, go back to using Basic.

Interface headers

[msobkow]

If your interface "classes" don't define all the methods you need to access an object, your architecture is screwed up. If you have to do typecasting, the interface should provide a method which is used to identify the correct class/interface for casting.

Casting without knowing what kind of object you're dealing with isn't a "bug" -- it's a shitty developer writing crap code who should be fired.

Re:

[msobkow]

Note: "struct" overlays are another issue entirely, but even they should have a header field that lets you know how to cast the overlay.

But is it a problem...

[Travelsonic]

with the language itself, or an issue that boils down to the coders, and how attentive they are to the vulnerabilities while they are producing the code for whatever they are working on?

My thought is that it is the latter (that it boils down to the coders, and their attentiveness + planning out their work to avoid such issues, but that's just one opinion.

Re:

[david_thornley]

It's something of an "attractive nuisance" feature. It makes it easy to write bad code. There's a lot of those in C++, if less than there used to be.

The problem is with downcasts, from superclasses to subclasses. If you use dynamic_cast, you get the null pointer for invalid casts, so if you test for that in your code everything's fine. (If you don't test in your code, you'll probably find out fairly fast anyway, since you'll be trying to dereference nullptr.) However, dynamic_cast is often too slow.

Re:

[Travelsonic]

I see what you mean, and learned quite a bit from your post. I never considered that before. Been a while since I actually learned things from a conversation on Slashdot (versus bickering over mindless crap).