[Cryptography] Something that's bothering me about the heartbleed discussion.....

[Tom Mitchell]

On Thu, Apr 17, 2014 at 8:47 PM, Jerry Leichter <leichter at lrw.com> wrote:
> On Apr 17, 2014, at 10:28 PM, Peter Trei <petertrei at gmail.com> wrote:
>>
>> So it's not just OpenSSL.  It's every bit of code that *uses* OpenSSL, and
>> every bit of code the *uses* the code that *uses* OpenSSL.
>
>
> .......... This style of security hole could
> exist in server programs which don't use OpenSSL; indeed, which don't use
> crypto at all.
...........
> Fixing crypto code, and/or walling it off as you suggest, won't prevent
> Heartbleed  style bugs in other server code.
>
>
..........
> We've known for years that buffer overflows can be used for code injection.
> In Heartbleed, we're seeing the same problem being used for data
> exfiltration.
>
> Not quite.  What Heartbleed returns is the contents of memory returned by
> malloc().  If the memory allocator cleared memory on free, the actual value
> to an attacker of reading uninitialized memory would be zero.

> Ironically, the original Unix model - of forking a new process for each
> incoming connection - was safe, but it failed to scale.

In this case of buffer *flow errors most could be
minimized with calloc() and freez(free_after_zeroring).

And sure freez() is not a standard function....
realloc() could leak info so a reallocz() makes sense.
what else needs attention.

These names are almost silly but what common library functions are close enough
to be fixed and replacements dropped in with minimal worry i.e.
malloc() vs. calloc().

At the point in time that C was born it was an improvement over assembler.  But
that was then....

Another problem in the programming world is the mental baggage
too many folk carry.   In the early public going of "Go" I saw
request after request to make a "Go" interface for one terrible
old "C" library after another.  This caused many of the old dogs to
be kept and not replaced.

I am curious if a reverse mind set is possible.   i.e. Begin recoding
and replacing commonly used libraries with rewritten libraries
crafted with modern tools and modern languages that are
able to link to "C".

One value of this is languages like Python that have more and
more functionality coded in "C" could be improved at a foundational
level by replacing "C" as the foundation tool kit.   Replace Python
with your language of choice.

Emotionally programmers want to work in C because they want to
play with the "big boys and girls".   Establishing an ethic and culture
of value around an improved set of foundations could be a good thing.





-- 
  T o m    M i t c h e l l