[Cryptography] letter versus spirit of the law ... UB delenda est

Peter Gutmann pgut001 at cs.auckland.ac.nz
Sat Oct 24 23:34:01 EDT 2015


Jerry Leichter <leichter at lrw.com> writes:

>Unfortunately, that description covers only a tiny fraction of users of C
>today.

I would say it's actually miniscule, not just tiny.  Some data points:

* Measurements of deployed code

The SOSP'13 paper found that a minimum of 40% of all Debian packages have UB
issues (the figure could be much higher since they may not detect everything
that's there).  Taking this as representative of gcc-built Unixes in general,
that means that for any app you're running there's a nearly 50/50 chance that
it has gcc-inserted latent pathogens in it.

* Use of 'safe' libraries

OK, so we'll fix this by using carefully-written UB-safe libraries like David
LeBlanc's SafeInt or CERT's IntegerLib.  These libraries were written and
vetted not by J.Random coder but by security experts to safely handle integer
issues.

Only problem is that even with security experts creating the code, they still
trigger UB:

  http://blog.regehr.org/archives/593

If even experienced security conscious programmers can't write code that's
safe from gcc's breakage, how is J.Random programmer supposed to do it?

* Use of developers who write perfectly error-free code

John Gilmore pointed out in an earlier post that he addressed the problem by
writing perfect, UB-free code, and everyone else should just do the same.
Let's check some of that code (linked via www.toad.com/gnu) using a UB
analyser and see what we get...

  'In 1985 I wrote the "pdtar" program, which eventually became GNU Tar'
  
  I couldn't actually get to the point of running the analyser because of the
  avalanche of bugs like:

  error: non-void function 'fl_write' should return a value
  error: non-void function 'fl_read' should return a value
  error: too few arguments to function call, expected at least 2, have 1
    if (STDIN != open("/dev/null"))

Strike 1.

  'While at Cygnus I maintained the GNU Debugger (GDB) from 1990 through 1993'

  Unfortunately gdb 4.10 from 1993 was too old to build without rewriting way
  too much of it (e.g. use of varargs.h instead of stdarg.h), the closest I
  could get was gdb 4.18:

  Generated 4 warnings, see pstack.txt for details.

  A -Wall also produced lots of warnings, most weren't serious, variables set
  but never used, char * vs. unsigned char *, but some were certainly dubious:
  
  warning: cast to pointer from integer of different size [-Wint-to-pointer-cast].

Strike 2.

  'From 1996-2003 I co-created and sponsored FreeS/WAN'
  
  I grabbed FreeSWAN 2.0 from early 2003, but since it's patches to the Linux
  kernel and there's no easy way to build even the user-space apps I couldn't
  get any further on this.  However, attempts at building did turn up things
  like:
  
  # include "programs/pluto/constants.h" /* XXX this is crap */
  * XXX this is NOT the way to do things.
  * XXX should generate a diagnostic.
  XXX: Not very clean.  We manipulate the port of the ip_address [...]
  XXX: this is really ugly and only temporary until addrtot can [...]
  XXX This should be replaced by a call to the kernel [...]
  XXX the following hash is pretty pathetic 

  so I'll assume that the rest is going to be no better than pdtar or gdb, if
  I could get it to the point where the analyser would run on it.

Based on the above, I'd like to propose the gcc breakage hypothesis:

  With gcc as the adversary, it is not possible to write any nontrivial
  application that won't have latent pathogens inserted by the compiler.

Peter.


More information about the cryptography mailing list