> > 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 njs3at_private FreeBSD: Turning PC's into Workstations: www.freebsd.org
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:06:36 PDT