Paavo Helde
11/21/2008 4:55:00 AM
zr <zvirack@gmail.com> kirjutas:
> On Nov 20, 4:11 pm, Pete Becker <p...@versatilecoding.com> wrote:
>> On 2008-11-20 09:08:58 -0500, zr <zvir...@gmail.com> said:
>>
>>
>>
>> > Does usage of checked iterators and checked containers make code
>> > more secure?
>> > If so, can that code considered to be reasonably secure?
>>
>> Define "secure" and "reasonably secure".
>>
>> --
>> Pete
>> Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
>> Standard C++ Library Extensions: a Tutorial and Reference
>> (www.petebecker.com/tr1book)
>
> Obviously checked iterators make it easier to detect defects, but i am
> asking about security. By "secure" i mean resistant to malicious usage
> of the application and resistant to other hostile code. I will let the
> security experts define the term more precisely.
> By "reasonably secure" i mean the required security quality that
> production software software should meet (yes, if it asks for your
> credit card number, it should be more than just "reasonably secure").
> On second thought, it might have been better if i started with a
> question like "how can i learn to write secure C++ code?" - you are
> welcome to answer it as well.
Probably not the best place, there seem to be many groups
comp.security*.
In Perl for example there is some built-in support meant for enhancing
security (taint mode). In C++, there is no such built-in support, so the
topic is not really language-specific. I'm no expert, but it generally
comes down to having no memory access errors, and not trusting input
from uncontrolled sources.
I think checked iterators a la MSVC++ may actually help here a bit,
detecting some of memory access errors. Another similar aid would be to
use garbage collector instead deletes, recently advocated here by James
Kanze, to avoid accidental access to a wrong object. Another useful aid
in the same fashion would be to splitter the code by assert()-s for
obvious and non-obvious things (and of course taking care to not compile
it away in the final release). However, these are not silver bullets, so
just compiling your whatever code with checked iterators support does
not magically make it "reasonably secure", whatever that might be.
Anyway, one has to start from the software requirements. If some server
software must have the best possible performance and allows the remote
user to execute arbitrary system() or dynamic library calls, then there
are no security benefits from checked iterators or asserts, only runtime
costs pulling down the performance. Naturally, such software should be
used only in a trusted network.
Paavo