Re: EMERGENCY: new remote root exploit in UW imapd

[rotel () indigo ie (Niall Smart)]

> > In some ways, it is depressing to find this new hole.  Programmers are
> > still making the same mistakes they have made for years.  Doesn't anyone
> > learn from the past?  Can strcpy() ever be used safely?  Perhaps the
> > software development community, and certainly those writing network service
> > daemons that run as root, should discontinue using *any* C library
> > functions that do not include bounds checking information, such as
> > sprintf(), strcat(), and strcpy().  Yes, they *can* be used safely but the
> > potential for misuse is too great.  When will we learn?  When?
>
> C should not be used for trusted programs.  The lack of true arrays
> with array bounds checking alone makes it too hazardous.  How many
> buffer overflow attacks would we hear about if the trusted server
> programs were written using a language with bounds checking like
> Modula-2 or Ada?  Zero.
>
> The Internet is becoming a critical part of society.  Can we afford to
> rely on an inherently dangerous programing language?

We can't afford to start making incorrect attributions as to the
cause of our security problems, thats for sure.

C is not an inherantly dangerous programming language.  The
specification of the language has absolutely nothing to say about
how it is executed; it is possible to write a C compiler which
generates bounds checking code which is as effective as any produced
by a Modula or Ada compiler.  See, for example,
http://fox.doc.ic.ac.uk/~phjk/BoundsChecking.html.  Also see "Safer
C: Developing Software for High-Integrity and Safety-Critical
Systems, Les Hatton" for an interesting discussion of why the
vilification of C doesn't really make sense.

There are at least 3 ways to solve the problem of buffer overflows:

 1) Use a language which doesn't involve manipulation of buffers at
    the language level, e.g. Java.

 2) Use a compiler which will generate code such that it will
    never overflow a buffer, e.g. one of the Ada/Modula/Pascal
    compilers, or the hypothetical bounds checking C compiler.

 3) Write programs which will never overflow their buffers.

Options 1 and 2 currently require you to change your programming
language; there are obvious implications in switching from a mature,
portable and well-understood language like C/C++, there are also
significant performance penalties in bounds checked code which make
its use impossible in many important cases.

The problem, as the original poster says, is that exercising option
3 is currently too difficult.  The ANSI C string handling functions
are simply error prone.  With this in mind I begin about a month
ago on a project to create a string handling library which makes
buffer management significantly easier, while still maintaining an
acceptable level of efficiency and supporting common C programming
idioms.  There are other interfaces, such as file access which are
also error prone to a degree which I am also looking at.  I haven't
had the time to spend as much time on this project as I would have
liked but I should get it released before the end of the summer at
which time I'll post an announcement here.  The code will be under
a BSD style copyright.

The library is not fool-proof, but fools and people unaware of the
issues shouldn't be writing software that executes with elevated
priviledges.  To write secure programs you need programmer education
and the tools and techniques to support it.  If you provide only
the tools, like a bounds checking C compiler, then your buffers
will be safe but people will use rand() for cryptography, or system()
arbitrary text; if you have the education but no decent tools then
you _will_ repeat silly buffer mismanagement mistakes, and I think
this is the crux of the problem.

Regards,


Niall

--
Niall Smart.        PGP: finger njs3 () motmot doc ic ac uk
FreeBSD: Turning PC's into Workstations: www.freebsd.org