Bugtraq mailing list archives
Re: EMERGENCY: new remote root exploit in UW imapd
From: rotel () indigo ie (Niall Smart)
Date: Sat, 18 Jul 1998 00:51:55 +0000
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
Current thread:
- N-Base Vulnerability Advisory, (continued)
- N-Base Vulnerability Advisory TTSG (Jul 20)
- IRIX 6.4 ioconfig(1M) and disk_bandwidth(1M) Vulnerability SGI Security Coordinator (Jul 20)
- IRIX 6.3 & 6.4 mailcap vulnerability SGI Security Coordinator (Jul 20)
- Bounds Checking Aleph One (Jul 20)
- Re: Bounds Checking Ari Heitner (Jul 21)
- Re: Bounds Checking Andrew McNaughton (Jul 21)
- Re: EMERGENCY: new remote root exploit in UW imapd Andy Church (Jul 17)
- Re: EMERGENCY: new remote root exploit in UW imapd Kragen (Jul 21)
- Re: EMERGENCY: new remote root exploit in UW imapd Craig Spannring (Jul 21)
- Re: EMERGENCY: new remote root exploit in UW imapd Kragen (Jul 21)
- Re: EMERGENCY: new remote root exploit in UW imapd matt (Jul 17)
- Re: EMERGENCY: new remote root exploit in UW imapd Niall Smart (Jul 17)
- Bounds checking - historical aside Russell Fulton (Jul 20)
- Re: Bounds checking - historical aside Brett Glass (Jul 21)
- Re: EMERGENCY: new remote root exploit in UW imapd Alex Belits (Jul 20)
- Re: EMERGENCY: new remote root exploit in UW imapd Kragen (Jul 21)
- Bounds checking - historical aside Russell Fulton (Jul 20)
- Re: EMERGENCY: new remote root exploit in UW imapd Allen Smith (Jul 20)
- Re: EMERGENCY: new remote root exploit in UW imapd Allanah Myles (Jul 20)
- Re: EMERGENCY: new remote root exploit in UW imapd Dave Andersen (Jul 21)
- Re: EMERGENCY: new remote root exploit in UW imapd Jim Greene (Jul 21)
- Re: EMERGENCY: new remote root exploit in UW imapd Peter Jeremy (Jul 21)
- Re: EMERGENCY: new remote root exploit in UW imapd IBS / Andre Oppermann (Jul 21)