Expanding the list of "Hardened Packages"

[Florian Weimer]

On 04/23/2013 11:36 PM, Kevin Kofler wrote:
> Moving from C/C++ to a slower language is neither helpful nor necessary. If
> you really want full bound checking, it can be added to C/C++ rather than
> moving to a completely different language, and you'd still get the other
> benefits of C/C++, in particular, fast native code. It shouldn't be worse
> for peformance than switching to another language: After all, the other
> languages have to do the bound checking as well!

At least you can avoid pointless discussions with developers if the 
overhead is unavoidable. 8-/

> I shall also note that vulnerable C++ code is mainly code which uses C-style
> data structures for whatever reason (often, interfacing with C-only
> libraries). If we all wrote pure Qt code, there would be little to no buffer
> overflow vulnerabilities. It's much harder to overflow a QString by accident
> than a char *. (The STL is similar there, but IMHO the STL is a horrible
> runtime library and should be replaced by QtCore or a subset of it. :-)

The standard container library has some rather strange stuff, like 
operator[] on array-like containers which doesn't do bounds checking. 
To get bounds checking, you have to use the at() member function instead.

Furthermore, operators are assumed to be cheap to copy, so they are 
usually implemented as pointers.  It is theoretically possible to make 
sure that the pointed-to container elements are live or that the 
iterator does not stray out of bounds, but the debug mode which does 
that is too slow for production use.

There is some fairly horrible stuff, like std::copy:

<http://en.cppreference.com/w/cpp/algorithm/copy>

You can pass a std::vector<T>::iterator (say, the result of begin()) as 
the output iterator, but it's your job to ensure that there's enough 
space.  Just like strcpy, and we all know how well that worked in practice.

That being said, my recent experience *writing* C++03 code has been 
rather positive.

-- 
Florian Weimer / Red Hat Product Security Team