Clearing sensitive in-memory data in perl

[Perry E. Metzger]

Steve Furlong <demonfighter at gmail.com> writes:
> On 9/13/05, Steven M. Bellovin <smb at cs.columbia.edu> wrote:
>> There's an interesting tradeoff here: which is a bigger threat, crypto
>> secrets lying around memory or buffer overflows?  What's your threat
>> model?  For the average server, I suspect you're better off with Java,
>> especially if you use some of its client-side security mechanisms to
>> lock down the server.  Under some circumstances, you could do a
>> call-out to a C module just for the crypto, but it's by no means
>> obvious that that's a major improvement.
>> 
>> Again -- what is your threat model?
>
> Other important questions for programmers are, how good are you? How
> good does the process allow you to be?
>
> My answers are, I'm quite a good programmer. (Pardon the ego.) I'm
> careful and methodical and very seldom have buffer overruns or unfreed
> memory even in my first drafts. For me, my expected code quality in C
> and C++ is balanced against the black box behaviour of Java's runtime
> engine.

I think you're wrong to operate on the assumption that even a very
good programmer can be more vigilant against buffer overflows than a
language that performs bounds checking. Even extremely good
programmers are human beings. I think I'm a very good programmer, but
I make mistakes, and in security, mistakes cost big time.

There is also the question of leverage -- if there is a bug in a
bounds checker in a language implementation, fixing it stops huge
numbers of bugs people didn't know about. Fixing buffer overflow bugs
in a C program helps only that program.

Generally speaking, I think software with a security impact should not
be written in C.

What the world really needs is something between C++ and C -- a
language with very clean obvious semantics (like C) which does run
time bounds checking and strong typing, though it also needs explicit
escapes in the type system so you can write things like device drivers
in it. It probably also should not require run time garbage
collection, if only so kernel code can be written in it.

Perry

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