Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by timothy on from the incentives-matter dept.

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.

73 comments

  1. Gee... by Anonymous Coward · · Score: 0, Insightful

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

    Just another reason to avoid C++.

    1. Re:Gee... by Anonymous Coward · · Score: 0

      In which way reported?

    2. Re: Gee... by Anonymous Coward · · Score: 1

      Just change to ADA instead.

    3. Re: Gee... by 0123456 · · Score: 1

      Just change to ADA instead.

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

    4. Re:Gee... by Phronesis · · Score: 1

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

    5. Re:Gee... by maligor · · Score: 2

      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.

    6. Re:Gee... by 0123456 · · Score: 1

      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.

    7. Re:Gee... by JesseMcDonald · · Score: 2

      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:

      -- Monoid laws:
      -- x <> mempty == x
      -- mempty <> y == y
      -- (x <> y) <> z == x <> (y <> z)
      class Monoid a where {
      mempty :: a;
      (<>) :: a -> a -> a;
      }

      instance Num a => Monoid (Sum a) where {
      mempty = Sum 0;
      Sum x <> Sum y = Sum (x + y);
      }

      instance Monoid [a] where {
      mempty = [];
      x <> y = x ++ y;
      }

      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
    8. Re:Gee... by Anonymous Coward · · 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 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.

    9. Re:Gee... by lgw · · Score: 2

      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.
    10. Re: Gee... by Anonymous Coward · · Score: 0

      What about function pointers with arguments cast to void pointers so a function doing callback doesn't need to know exactly what parameters are being passed to the callback?

      Seems pretty common in C in my experience.

    11. Re:Gee... by Anonymous Coward · · Score: 0

      Good C code rarely needs casting, if at all.

      Muahahah...

      There's so many casts in C, half of them being implicit because you can cast any void * into any pointer without the compiler complaining. Just try to compile your C code with a C++ compiler, and you'll see how many "trivial code' is littered with implicit casts now valid anymore in C++. Do I need to mention the varargs functions, the implicit casts from one integer to another? (which plagues C++ too, because of backward compatibility).

      Back to the subject, casting in C++ should be less common than in C and in Java or C#. Less than in C because C++ has both OO and generic facilities, and less than in Java/C# because C++ tend to not rely that much on OO features (e.g. templates in C++ does not relay on OO, like generics in Java and C# do).

      The problem is: C++ code comes from somewhere. Half the time it comes from a C codebase upgraded to C++, and there you have all the dumb void * littering the code flashing their underwear (half of those casts wrong anyway). And the other half the code was written by people who were breastfed on Java-like OO programming style (and who insist in believing that if your function is not a virtual member function inherited from an interface all the way back to Object, then your function has no meaning in life), and who dump code in terms of hierarchies of classes you can't use without downcasting everywhere.

      Remember: A generic sorting of a collection doesn't need cast nor virtual dispatch in C++.

    12. Re:Gee... by Anonymous Coward · · Score: 0

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

      The FUD against used defined operator overloading is getting a bit old, considering A LOT of languages do support it despite James Gosling's omniscient wisdom on the subject:

      http://stackoverflow.com/a/194889

    13. Re: Gee... by Anonymous Coward · · Score: 0

      Yes it's common for event libraries. It's also not the kind of obfuscated casting that leads to difficult to detect bugs, simply because you're not likely to accidentally pass the wrong function pointer.

      That said, I despise callbacks for this and other reasons (causes issues with ownership semantics, use after free issues, recursion issues, and is a nightmare when integrating libraries). Implement your algorithm using pull-style semantics and you'll get stronger typing for free.

      C has its limitations. But just because language X makes callbacks slightly safer is not something to be smug about. Now if language X supports guaranteed tail recursion, lambdas, and other niceties, then using callback continuation style programming can make alot of sense. If not, as is the case with C++ as well as C, then you really shouldn't be using callbacks if you can help it.

      Thats why I don't bother much with C++. Most of the benefits it has over C pale in comparison to what other languages provide. C still outshines C++ when it comes to simplicity, transparency, and the ability to reason about its runtime costs. When those qualities are paramount, use C. When they're not, use an appropriate language.

    14. Re:Gee... by Keith+Henson · · 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.

      --
      End MGM. Get prospective parents of boys to Google: Men do complain
  2. They've only just discovered this? by Viol8 · · Score: 1

    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...

    1. Re:They've only just discovered this? by Viol8 · · Score: 1

      That should have read "caught at compile time"

    2. Re:They've only just discovered this? by Anonymous Coward · · 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....

    3. Re:They've only just discovered this? by Anonymous Coward · · Score: 0

      Er, dynamic_cast doesn't throw an exception; it returns NULL if it fails.

    4. Re:They've only just discovered this? by Viol8 · · Score: 1

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

    5. Re:They've only just discovered this? by Anonymous Coward · · Score: 0

      Er, dynamic_cast doesn't throw an exception; it returns NULL if it fails.

      Sure it does. dynamic_cast on an invalid reference throws std::bad_cast because you cannot have a NULL reference.

    6. Re:They've only just discovered this? by Cassini2 · · Score: 1

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

      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.

  3. Yawn -- Another Closed Source Problem by Anonymous Coward · · 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.

    1. Re:Yawn -- Another Closed Source Problem by Anonymous Coward · · 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.

    2. Re:Yawn -- Another Closed Source Problem by jonkalb · · 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.

    3. Re:Yawn -- Another Closed Source Problem by Anonymous Coward · · Score: 1

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

    4. Re: Yawn -- Another Closed Source Problem by Anonymous Coward · · Score: 0

      While this comment makes me laugh, it also makes me think there really is something to be said about "number of eyes" if we extrapolate that as being the size of the talent pool.

      Many here are suggesting to program in much lesser known languages such as ADA. But I think that having access to a large pool of talented programmers, and Facebook is doing that with a simple public bounty, is a benefit that C++ has over many other languages. For closed source software, you can easily built really talented teams with code review processes. For public open source code, even better!

    5. Re:Yawn -- Another Closed Source Problem by edtice1559 · · Score: 1

      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 complicated bugs may be found out this way. When things get large, you have experts who understand individual subsystems really well but for use cases that cross multiple sub-systems, subtle errors are made. These can't be found by looking at the code unless you know both subsystems very well. But there may not be anybody in that position so the bugs stay around a long time. For this type of situation you need better tools and a lot of progress has been made in this area. But given the number of bugs that get found in even good production software, there is still clearly a gap to fill.

  4. Rants against the C++ language by Anonymous Coward · · Score: 1

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

  5. No they haven't by Burdell · · Score: 3, 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.

    1. Re:No they haven't by Anonymous Coward · · Score: 0

      Do they still have a Rambling Wreck?

    2. Re:No they haven't by fnj · · Score: 1

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

  6. Perl doesn't have that problem! by MagickalMyst · · Score: 1

    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.
  7. $100k? by Anonymous Coward · · Score: 0

    Please tell me these clowns didn't get 100 large for writing a paper about a problem that has been known since the 1970's.......?

    Please tell me that....?

    1. Re:$100k? by Anonymous Coward · · Score: 0

      Wait until they get 200k for telling us that cornflakes go soggy because milk is wet...

  8. Debug runtime typing system by edtice1559 · · Score: 4, Interesting

    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.

    1. Re:Debug runtime typing system by Anonymous Coward · · Score: 0

      You could easily implement that (at higher runtime penalty though) by always using dynamic_cast instead of static_cast in debug mode.

      I don't really understand why dynamic_cast has to resort to string comparisons, making it so slow. There should be a way to do some full program optimization and reduce all class strings by string atoms (integers) that can be compared fast, as long as things reside in the same library.
      Probably not an easy task, but compiler writers are clever anyway.

    2. Re:Debug runtime typing system by friedmud · · Score: 1

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

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

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

      This is a no brainer...

    3. Re:Debug runtime typing system by Anonymous Coward · · Score: 0

      Sounds good.

      Also, hasn't bad type casting been around since C (and probably before)?

      At least they've proposed a mechanism to help, I certainly wouldn't call this a "new emerging problem with the C++ language."

    4. Re: Debug runtime typing system by loufoque · · 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.

    5. Re:Debug runtime typing system by phantomfive · · Score: 1

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

      --
      "First they came for the slanderers and i said nothing."
    6. Re:Debug runtime typing system by edtice1559 · · Score: 3, Informative

      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

  9. How about using a safer language? by aaaaaaargh! · · Score: 0

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

    1. Re:How about using a safer language? by Anonymous Coward · · Score: 0

      As much as I like and advocate Ada, it certainly is vulnerable to this sort of error too. Explicit type conversions are risky, and many developers will use Unchecked_Conversion to throw away all type safety. I am not sure if you can get the same sort of error as the paper authors found here.

      My experience in C++ is that most people use the C-style cast rather than the more verbose and limited C++ casts. C-style casts or reinterpret_cast will let you get in all sorts of trouble. It did not seem like the CaVer tool currently handles C-style casts or anything other than static_cast and dynamic_cast, a clear opportunity.

  10. Basic fact flub in TFA by Anonymous Coward · · 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.

  11. OMFG! by jimpop · · Score: 1, Informative

    1) learn something that older people learned decades ago

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

    3) profit!

    1. Re:OMFG! by swillden · · Score: 1

      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.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    2. Re:OMFG! by jimpop · · Score: 1

      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.

    3. Re:OMFG! by swillden · · Score: 1

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

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    4. Re:OMFG! by edtice1559 · · Score: 3, Informative

      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.

    5. Re:OMFG! by Anonymous Coward · · Score: 0

      They also built a tool

      That's the problem. A lot of new programmers nowadays assume that if it's going to be a problem, some tool / IDE component / runtime checker / compiler error / etc. will catch it and not allow it to happen, or prevent the program from building at all automagicly.

      Hell, I was in a Java II class about a year ago and one of the smartest students in the room asked about why their program was not working. (NULL pointer exception.) When I explained to him he needed to check for a NULL in an array (and allocate the object if found) before attempting to use it, he said: "Well if it's important, then the instructor will explain it." The only problem was that the instructor WAS trying to explain it, multiple times, and having no luck.

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

      Even worse is the fact that when the documentation DOES exist, it's rarely used. I remember a wine bug on Civilization 5 that turned out to be a bug in the game. Why? because the game was dependent on the fact that an NTFS filesystem would store it's directory listings alphabetically, without doing any checking to ensure the returned directory listing was alphabetized. The programmers assumed the OS was alphabetizing the list, but the TechNet docs say:

      "The FindFirstFile function opens a search handle and returns information about the first file that the file system finds with a name that matches the specified pattern. This may or may not be the first file or directory that appears in a directory-listing application (such as the dir command) when given the same file name string pattern. This is because FindFirstFile does no sorting of the search results. For additional information, see FindNextFile."

      Emphasis mine.

      We don't even have the professionals reading the documentation of something so basic, and the tools are not going to detect this either. So that document warning of the dangers, is effectively useless. Like most history books :P
      The reason I bring this up is to show it's not just a student problem, but rather a problem that affects the entire industry.

      The takeaway? Having all of these tools is nice, but they should not be used as a crutch. Programmers should have enough knowledge about their chosen language to be able to use it relatively safely without being over-reliant on automated checking tools. Unfortunately, too many programmers nowadays out right depend on them being there, and have no idea what to do when they encounter something the automatic tools don't handle for them. Most of them barely know that the documentation even exists, and will only look at it as a last resort. Then you give them something that can be dangerous if misused, and you're surprised that shit hits the fan? You may as well give a three-year-old the keys to your car and let them out on the interstate, you'll get the same level of BS, and even worse consequences.

      This problem can be fixed, but it requires that programmers take on MORE responsibility for their code. Not less by giving it to automagic tools that do things for them. (They need to be able to fail.)

    6. Re:OMFG! by jimpop · · Score: 1

      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.

    7. Re:OMFG! by edtice1559 · · Score: 1

      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 that older people knew. Software systems have gotten much larger over time. There are whole new classes of bugs (like the ones in the article) that are introduced because the application is too large for the programmer to be familiar with the entire thing. No amount of knowledge of the programming language will help. It's often impossible to predict the consequences of changing one part of a system. For all we know, the identified defects are the result of two changes that were each correct in isolation but the combination was dangerous. It's easy for that to happen with multiple people committing code. I don't understand your desire to take something as complicated as writing software and simply say that all problems are because other programmers aren't as good as you are. It's a complex domain and we should be glad to have additional tools.

    8. Re:OMFG! by jimpop · · Score: 1

      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++.

    9. Re:OMFG! by edtice1559 · · Score: 1

      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 audit every cast in the application. But even then you won't find this type of defect. Because the actual cast is never the bug. It's the semantic meaning of the data before and after the cast. And for that, no amount of C++ knowledge in the world will help you. You need to know the application domain and all parts of it. Your philosophical points may have validity. But it's hard to take them seriously when you can't (or won't) even use very basic terminology correctly. The fact that the words are new to you indicates that you've dismissed an entire part of the tools ecosystem without even learning about it.

    10. Re:OMFG! by jimpop · · Score: 1

      > 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.

  12. A minor correction. by Kickasso · · Score: 1

    plays an essential role in misusing polymorphism in C++

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

    1. Re: A minor correction. by loufoque · · Score: 1

      Unless you're doing CRTP.

    2. Re:A minor correction. by Viol8 · · Score: 1

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

    3. Re: A minor correction. by Kickasso · · Score: 1

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

    4. Re:A minor correction. by Kickasso · · Score: 2

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

    5. Re:A minor correction. by Anonymous Coward · · Score: 0

      Why would you do that?

    6. Re:A minor correction. by Viol8 · · Score: 1

      *boggle*

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

    7. Re: A minor correction. by loufoque · · Score: 1

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

  13. Now apply it to movies by Anonymous Coward · · Score: 0

    If they can fix bad casting in C++, maybe they can fix it for the movie industry.

  14. Interface headers by msobkow · · Score: 2

    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.
    1. Re:Interface headers by msobkow · · Score: 1

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

      --
      I do not fail; I succeed at finding out what does not work.
  15. Classy by Anonymous Coward · · Score: 0

    It's a new "class" of bugs. Get it?

  16. But is it a problem... by Travelsonic · · Score: 1

    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
    1. Re:But is it a problem... by david_thornley · · Score: 1

      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. (One solution, if compiler vendors wanted to support it, would be to make dynamic_cast faster, but that's outside the scope.) Therefore, every time you cast from superclass to subclass, using static_cast, you need to know that you're casting to the right subclass.

      This means that the programmer has to keep track of the subclass, and any mistake is a potential security problem. That type of mistake is easy to make, and it's difficult to verify it's being done right.

      Given a situation like that, not being allowed to use dynamic_cast, I'd probably have virtual functions that would indicate the exact subclass something was, implementing my own type information system. This would make it harder to mess up, and easier to find if the programmer screwed up. That's not necessarily easy to retrofit, and it would be a pain if I tried maintaining something like that without being able to change upstream.

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
    2. Re:But is it a problem... by Travelsonic · · Score: 1

      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).

      --
      If you believe in privacy, and believe you have "nothing to hide" at the same time, you're a goddammed idiot
  17. In related news... by Anonymous Coward · · Score: 0

    Facebook hired, then immediately fired the researchers for exposing potential Facebook security flaws.