zr <zv*****@gmail.comkirjutas:
On Nov 20, 4:11*pm, Pete Becker <p...@versatilecoding.comwrote:
>On 2008-11-20 09:08:58 -0500, zr <zvir...@gmail.comsaid:
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
