Clearing sensitive in-memory data in perl

[Anne & Lynn Wheeler]

Ben Laurie wrote:
> gets is so not the problem. Using strings that _can_ overflow is the
> problem. That means wrapping the entire standard library.
> 
> And, of course, the issue is that every other library in the universe
> uses C-style strings (etc.), so unless we can all agree on a better
> paradigm, we're screwed.

note that various infrastructures ... have made the length field an
integral characteristic of nearly every piece of storage and that
automatic use the length values an integral piece of every operation;
extended from the lowest level interrupt handlers and device drivers ...
up thru the most complex application code. it isn't just a
characteristic of the high level application libraries ... but nearly
every aspect of the operation environment.

these length-based paradigms aren't only limited to programming
languages (other than C) ... but can also be found in infrastructures
that are pure assembler code.

the other way of viewing the string issue is that the length isn't
explicit ... the default c-based length paradigm is implicit based on
the pattern of data in a buffer ... which tends to create length related
vulnerabilities from simple data manipulation operations (you might
generalize this as a dual-use vulnerability). this is further compounded
when there is a field/buffer that is empty and doesn't yet have any data
to establish an implicit data-pattern defined length.

explicitly separating the length attribute from any data pattern
characteristic would make the infrastructure less vulnerable to length
mistakes resulting from simple data manipulation operations. it would
also enable a single, consistant length paradigm for both field/buffers
that contain data patterns and field/buffers that are empty and don't
contain data patterns.


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