Facebook Awards Researchers $100k For Detecting Emerging Class of C++ Bugs 73
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... (Score:1)
Just change to ADA instead.
Re: (Score:2)
Just change to ADA instead.
Do the words 'unchecked conversion' mean anything to you?
Re: (Score:2)
Re: (Score:2, Insightful)
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: (Score:3)
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: (Score:2)
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: (Score:1)
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: (Score:3)
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: (Score:3)
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? (Score:2)
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: (Score:2)
That should have read "caught at compile time"
Re: (Score:2)
I suggest you go read your C++ book again. It only returns null for pointers.
Re: (Score:2)
On error, dynamic_cast returns NULL for pointers, and an exception for references. From cppreference [cppreference.com]:
Re: (Score:2, Interesting)
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 (Score:5, Funny)
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: (Score:1)
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: (Score:1)
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: (Score:1)
Actually, it's more of a troll than sarcasm.
Re: (Score:2)
Rants against the C++ language (Score:1)
And Stroustrup coming in 3.. 2.. 1..
No they haven't (Score:4, Informative)
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: (Score:2)
I once saw a clueless idiot write "University of Boston" for "Boston University".
Perl doesn't have that problem! (Score:2)
Sorry, I couldn't resist...
Comment removed (Score:5, Interesting)
Re: (Score:2)
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...
Comment removed (Score:4, Informative)
Re: Debug runtime typing system (Score:1)
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: (Score:2)
How about using a safer language? (Score:1)
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 (Score:1)
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! (Score:2, Informative)
1) learn something that older people learned decades ago
2) write document warning people, who ignored history..., of the dangers!!
3) profit!
Re: (Score:2)
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: (Score:2)
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: (Score:2)
Comment removed (Score:4, Informative)
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
> 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. (Score:1)
Here, FTFY. Kids, if you cast, you are doing polymorphism wrong.
Re: A minor correction. (Score:1)
Unless you're doing CRTP.
Re: (Score:1)
Even with CRTP it's avoidable, for the price of slightly increased verbosity.
Re: (Score:1)
It's not avoidable unless you're limiting yourself to a subset of CRTP.
Re: (Score:2)
Seriously? So you never cast a child class to a parent pointer? I don't think you do polymorphism at all.
Re: (Score:2)
Why would anyone want to? Cast is an explicit type conversion (see the standard, 5.4 [expr.cast]).
Re: (Score:2)
*boggle*
Don't worry about, go back to using Basic.
Interface headers (Score:3)
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: (Score:2)
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... (Score:2)
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: (Score:2)
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: (Score:1)