Clearing sensitive in-memory data in perl

Anne & Lynn Wheeler lynn at garlic.com
Tue Sep 13 16:18:00 EDT 2005


Steve Furlong wrote:
> 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. (To be clear: I don't suspect Sun of putting back doors in
> their engine.) And I'm experienced enough and old enough that I can
> hold my own in pissing contests with project managers who want to cut
> corners in order to ship a day earlier.
> 
> Implementation quality could be considered in the threat model. I've
> generally taken the programmers into account when designing a system,
> but I hadn't explicitly thought of well-meaning-but-incompetent
> programmers as part of the threat. Guess I should.

note that compared to some other languages .... a lot of C-language
buffer overflows can be attributed to C requiring the programmer to keep
track and manage various lengths (where in some number of other
languages, buffer length characteristics are built into basic object
characteristics and operations). i know of at least one production
implemented tcp/ip stack done in pascal ... which had no known buffer
related problems compared to the possibly hundreds of thousands that
have appeared in c-language based implementations.

large collection of past posts on buffer overflow related vulneabilities
http://www.garlic.com/~lynn/subpubkey.html#overflow

part of the issue is that there are hundreds of thousands of
applicantations being written ... with possibly only a couple hundred
mistake-free, careful programmers available world-wide. a possible
solution is to create a time-machine that allows for the limited number
of mistake-free, careful programmers to have several thousand hour work
days (along with the medical support to allow them to never sleep).

there are separate class of vulnerabilities related to dangling buffer
pointers and syncronization problems ... which are common to languages
that place the burden of allocation/deallocation burden on the
programmer (however, that is a distinct vulneability from c-language
placing burden of length management on the programmer ... and the
resulting mistakces).

some languages like apl ... large collection of past apl posts
http://www.garlic.com/~lynn/subtopic.html#hone

have abstracted both object length characteristics as well as storage
allocation/deallocation operations.

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



More information about the cryptography mailing list