[Cryptography] defaults, black boxes, APIs, and other engineering thoughts

Jonathan Thornburg jthorn at astro.indiana.edu
Mon Jan 6 16:01:47 EST 2014


> > Why not narrow it down?  PDF however is a huge project.  Pick the one 
> > thing that we all seem to revert to in any secure code discussion:
> > 
> >        buffer overflows in C.
> > 
> > Design the mod to current C language/libraries that best addresses the 
> > syndrome.

Widespread use of EXISTING compiler options which catch almost all
buffer overruns in C code would be a good starting point.  For example:
* AddressSanitizer does compiler instrumentation of memory accesses
  to catch almost all buffer overruns in C code at a cost of around
  a factor of 2 in CPU and < 12.5% in memory use, see
    http://code.google.com/p/address-sanitizer/
  for details
* bounded pointers (compiler represents all pointers "fat", i.e.,
  augmented with explicit lower/upper bounds maintained and checked
  at runtime) ==> also catches almost all buffer overruns, again at
  a factor-of-a-few cost in CPU + modest memory overheads

Right now some compilers have skeleton support for these:
* llvm and gcc implement AddressSanitizer for {x86,x86-64}, but is this
  production-ready?
* what about other platforms?
* gcc has had multiple bounded-pointers projects over the years, most
  recently "mudflap", but it's not even clear if this works reliably
* do debuggers grok this?

Once compiler support is solid, then a lot more grunt work (libraries,
debuggers, and all the other pieces of the software-development toolchain)
will still be needed before this can be used routinely by developers.

But ultimately, if security-critical OSs and applications routinely used
this sort of run-time protection, they'd be secure against a large class
of buffer overruns.  We have enough CPU and memory available today that
"wasting" a factor of 2 or 3 or even 10 on this might well be a good
tradeoff.



On the other hand... returning from security-geek-fantasy-land to the
real world...  right now there are still a lot of production OSs, even
ones that call themself "server OSs" (FreeBSD 10, here's looking at you!),
that don't even have ASLR (address-space layout randomization) turned on
by default.  This has a performance cost of only 1 to 3 percent!  Sigh.....

Indeed, how many binaries on *your* laptop still use gets() and sprintf()?

-- 
-- "Jonathan Thornburg [remove -animal to reply]" <jthorn at astro.indiana-zebra.edu>
   Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
   "There was of course no way of knowing whether you were being watched
    at any given moment.  How often, or on what system, the Thought Police
    plugged in on any individual wire was guesswork.  It was even conceivable
    that they watched everybody all the time."  -- George Orwell, "1984"


More information about the cryptography mailing list