Clearing sensitive in-memory data in perl

[Greg Black]

On 2005-09-17, Jerrold Leichter wrote (without retaining attributions):

>>>> So wouldn't the world be a better place if we could all agree on a
>>>> single such library? Or at least, a single API. Like the STL is for C++.
>>> 
>>> Yes, absolutely, but who is going to do it?
>> 
>> One could argue it has already been done.

It (the creation of such a library) has been done many times;
admittedly, widespread adoption has not happened at all.

>> There exists a widely available, freely available, well-implemented
>> example of something just like the STL for C++.  It is called
>> "the STL for C++".
>> 
>> a) Writing in C++ is easier than writing in C.

Only for people who find it easier to use a huge clunky tool
they will never fully know than a clean simple language which
can be used to write completely reliable software.  Of course,
C's simplicity is its danger:  any idiot who can spend a few
hours with a C for Dummies kind of book can imagine that he's
competent to write in C.  As with any sharp tool, careful use is
mandatory to avoid nasty cuts; thorough understanding is needed
to ensure safe handling.

We don't expect people to fly commercial aircraft without taking
the time to become suitably skilled.  We don't expect people to
start doing brain surgery without having appropriate training.
Software is complex stuff; it takes time to acquire skills with
it.  For those with the skills, C is an excellent tool.  It's
not perfect, but it's the best thing we have and it's well able
to do the things we ask of it.  The problem is bad programmers.

>> b) Porting legacy C to C++ isn't rocket surgery.  It can be done
>> incrementally.
> 
> And the STL is safer than C ... in what sense?  STL iterators are modeled on C
> pointers - warts and all.  An STL iterator can point to random memory just as
> easily as a C pointer.  An indexing operation into an STL vector or similar
> data structure is subject to exactly as much range checking as a C indexing
> operation.
> 
> Yes, there exist implementations of the STL that check such things - just as
> there exist implementations of C that check such things.  None appear to be
> widely used.  And, of course, while no standard *forbids* such checks, none
> *require* them, so (a) availability is spotty; (b) compilers typically contain
> no optimizations aimed at making such things efficient.

Agreed, the STL (and C++) is no answer.

> RISKS had a large number of messages on this topic back in 2002.  I wrote one
> long commentary (in RISKS 21.85 - see http://catless.ncl.ac.uk/Risks/21.85 for
> one on-line source) that I stand by to this day.  Very little has changed.

While you make some valid points in that article, I take issue
with much of it.  For instance, you cite "[a] large body of code
that provides bad examples" as one of the big faults with C.
This is just not a valid argument.  (Yes it's true: there is
such a body of code, but it's not an argument.)

The classic book of examples of bad programming, "The Elements
of Programming Style" by Kernighan and Plauger, dates back to
the days before C.  Its examples are in Fortran and PL/1.  It is
full of the same kind of blunders we are talking about here.
It's not the language, it's the programmers who are at fault.
The only reason that we see much in C is that, for the past 25
years, most widely-seen software has been written in C.

> (Actually, there has been a *bit* of improvement:  Microsoft submitted a
> proposal for a set of new string - and related - functions for standardization
> in the C library.  They differ from the classic functions in always having an
> explicit output buffer length.  Personally, I find the particular API typical
> of Microsoft - butt-ugly and a pain to use - and I *think* that the standards
> groups may be re-working them.  But one way or another, after all these years,
> we may eventually have safe alternatives - once we work throught the
> standardization process and get the stuff out there (I'd guess another 2 years
> at least before you can safely assume that it'll be available).

I haven't followed any news about that.  Anything that comes out
of Microsoft won't be worth considering -- nothing from there
has been good in the past, so there's no reason to think that
might change.  More to the point, it takes many years before
stuff like that becomes widely available (and therefore
usable).  We don't need new tools; we just to learn to use the
ones we have effectively.

The comments you make about seat belt and air bags don't make
much sense either.  Their purpose is to save our lives after we
have made a potentially fatal mistake.  After all, there's a big
mess to clean up when those things are used, so it's not like we
want them to play an active part.

This is also a question of culture.  Everybody thinks they have
the right to drive but no responsibility to learn how to do it
well.  So, since bad driving causes so many deaths, governments
mandate all sorts of after-the-accident safety gadgets.  If they
mandated proper skill and attitude training before allowing
people to drive, we'd save a lot more lives.  Equally, if the
software community started to expect suitable training and
skills in programmers, we'd solve most of our current problems.

To return to the original point.  Every serious C programmer who
cares about his work has known forever that the C standard
library serves only as a basic low-level building block for use
in creation of real libraries that suit the project at hand.  It
also contains a few simple functions, like gets() and the other
maligned string-handling functions, that serve as quick and
dirty gadgets for programmers to use when writing a quick bit of
test code for their own use where security and safety are not at
all important, but checking something else quickly is the goal.

I have written C code that has been running daily in commercial
environments for over 20 years that has never had a failure, as
a result of buffer overflows or any other bugs.  I'm not unique.
But I do see lots of people writing C who seem to think that
they have the right to do it as badly as they like, even though
they know you have to be properly qualified to work in other
fields.

Greg

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com