Facebook hands hackers $100k for breaking browsers Four researchers have scored US$100,000 from Facebook for revealing 11 bugs affecting platforms including the Chrome and Firefox browsers using novel vulnerability discovery methods. The Georgia Institute of Technology team of PhD students Byoungyoung Lee and Chengyu Song, and professors Taesoo Kim and Wenke Lee discovered the …
Very cool.
An important OOP feature is type casting that converts one object type to another. Type conversions play an important role in polymorphism. It allows a program to treat objects of one type as another so that the code can utilize certain general or specific features within the class hierarchy. Unlike other OOP languages—such as Java—that always verify the safety of a type conversion using runtime type information (RTTI), C++ offers two kinds of type conversions: static_cast, which verifies the correctness of conversion at compile time, and dynamic_cast, which verifies type safety at runtime using RTTI. static_cast is much more efficient because runtime type checking by dynamic_cast is 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_cast. However, the performance benefit of static_cast comes with a security risk because information at compile time is by no means sufficient to fully verify the safety of type conversions. In particular, upcasting (casting a derived class to its parent class) is always safe, but downcasting (casting a parent class to one of its derived classes) may not be safe because the derived class may not be a subobject of a truly allocated object in downcasting. Unsafe downcasting is better known as bad-casting or type-confusion.
Yes, we are still in the Middle Ages of Coding, with barely adequate programming languages, EULAs, witches, "here be dragons" and mandragore sprinkled all over everywhere, and bad reflexes (performance >> security) are still prevalent. But we are slowly getting there.
But we are slowly getting there.
True, for sufficiently large values of slowly.
One big problem is that research is far ahead of most practice - and has been for decades, probably since the '70s. Few development organizations regularly use even the widely-available, well-understood free and commercial tools for static and dynamic checking, for example. Even fewer seem to use things like fuzzers1, code-coverage statistics, intelligent testing engines, etc. And I suspect very few have anyone paying attention to research in the area, except the occasional oddball doing it on his or her own time.
So while work like this - both offering a new technique and using it to discover issues in commonly-used software - is very welcome, the dreary fact is that typical software development teams aren't even using techniques as old as lint. (How many of you have worked on teams that routinely ignored compiler warnings?)
And this is why we need bug bounties - not just to give researchers an incentive to find and report problems, but to show the beancounters at the bounty-paying companies what kind of RoI they might realize from imposing better development practices.
Of course, Oracle doesn't need a bug-bounty program. Adam Gowdiak will keep them amply supplied with JRE bugs for the rest of time. Ellison has cleverly deduced that by being an arrogant jerk, he can get researchers to report bugs in his software just for the satisfaction.
1The situation here seems to be a bit better with web development - we see a number of our customers running various web-testing packages, free and commercial. I suspect that's a combination of the simplicity of running those packages and a dim recognition among upper management that public-facing web apps are often riddled with security holes that can lead to expensive compromises.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
