Clearing sensitive in-memory data in perl

[Victor Duchovni]

On Thu, Sep 15, 2005 at 08:51:02PM -0700, Bill Frantz wrote:

> On 9/13/05, perry at piermont.com (Perry E. Metzger) wrote:
> 
> 
> >Generally speaking, I think software with a security impact should not
> >be written in C.
> 
> I agree.  I also note that Paul A. Karger and Roger R. Schell, in their
> paper, "Thirty Years Later: Lessons from the Multics Security
> Evaluation" state:
> 

While some of the fault is perhaps in the core language, my contention is
that the real problem is the anemic standard C-library. When working on C
projects that have (and uniformly use) their own mature string handling
libraries (I was a contributor to Tcl in the 90's and am now working
in Postfix) I found that buffer overflows (and with Tcl for reasons I
won't go into here also memory leaks) were a non-issue in those systems.

With either Tcl_DString or VSTRING (Postfix), one simply loses the
habit of needing to keep track of buffer lengths. When combined with a
compatible I/O interface (say VSTREAM), argument vector library (ARGV)
hash table library, ... one no longer in practice manipulates bare
null-terminated string buffers except when passing (usually read-only)
content to system calls via the C-library.

I continue to write code in C, free of buffer overflows and memory leaks,
not because I am more manly than the next programmer, but because I am
attracted to working on well-designed systems, whose designers took the
time to develop a richer set of idioms in which to construct their work.

My view is that C is fine, but it needs a real library and programmers
who learn C need to learn to use the real library, with the bare-metal
C-library used only by library developers to bootstrap new safe
primitives.

-- 

 /"\ ASCII RIBBON                  NOTICE: If received in error,
 \ / CAMPAIGN     Victor Duchovni  please destroy and notify
  X AGAINST       IT Security,     sender. Sender does not waive
 / \ HTML MAIL    Morgan Stanley   confidentiality or privilege,
                                   and use is prohibited.

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