Slashdot Mirror
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.
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...
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.
And Stroustrup coming in 3.. 2.. 1..
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.
Variable types are interpreted dynamically during runtime in Perl, depending on how the variable is called.
Sorry, I couldn't resist...
Political correctness is really just herd psychology pushed by insecure people who desperately seek social conformity.
Just change to ADA instead.
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.
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.
1) learn something that older people learned decades ago
2) write document warning people, who ignored history..., of the dangers!!
3) profit!
Just change to ADA instead.
Do the words 'unchecked conversion' mean anything to you?
Because no one ever cast int to pointer or vice versa in K&R C.
Here, FTFY. Kids, if you cast, you are doing polymorphism wrong.
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.
I do not fail; I succeed at finding out what does not work.
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.
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.
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 Haskell, where overloading is only allowed in the context of a typeclass instance:
There can be any number of instances of the Monoid typeclass, but for every implementation of the (<>) operator the arguments and result must be the same type, and (per the Monoid laws—which admittedly are only convention, and not enforced by the type system) the implementation must be associative and have mempty as its left and right identity. The same overloading rules apply to the named function mempty and the operator (<>). Since Haskell permits arbitrary sequences of symbols as operator names, there is little pressure to abuse existing operators to new purposes, and while Haskell libraries tend to make extensive use of custom operators one rarely encounters them same issues that C++ project face with operator overloading.
The nearest C++ equivalent would be to define the built-in operators as members of various abstract base classes, and only allow a named function or operator to be redefined in classes which inherit their interface from the relevant base class. This unfortunately runs into some issues regarding polymorphism due to limitations of C++'s type system; for example, the implementation of mempty needs to be selected based on its return type, while C++ only supports selecting a class based on the type of the implicit parameter "this".
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
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 true with C++ (because of the stricter typing and abuse of overly specialized types; because of ABI issues; because of the way C++ programmers, like Java programmers, rely on mountains of third party libraries, often creating conflicts).
if you feel the need to cast you've probably coded yourself into a corner and should think about refactoring.
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.
If you believe in privacy, and believe you have "nothing to hide" at the same time, you're a goddammed idiot
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 learn the details of the 3 key library container classes: string, vector, and map. Poor coder choices causing significant (unnecessary!) performance hits was a bad enough problem that the standard had to add a fixed-sized array class, as even the simplest stuff like pre-allocating a vector when you know its size was beyond most coders. Sad, really.
And for goodness sake people, don't re-invent anything in std::algorithm! Stuff like inplace_merge or nth_element is really error prone to write yourself, as much fun as it might be to finally use that algorithms textbook from college.
Socialism: a lie told by totalitarians and believed by fools.
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.
End MGM. Get prospective parents of boys to Google: Men do complain