Bugtraq mailing list archives
Re: EMERGENCY: new remote root exploit in UW imapd
From: cts () INTERNETCDS COM (Craig Spannring)
Date: Thu, 16 Jul 1998 17:35:04 -0700
Anonymous writes:
the saved instruction pointer on the stack is overwritten with a altered value that can result in the execution of arbitrary machine code, due to coding errors in the IMAP server.
^^^^^^^^^^^^^ Strictly speaking, this is true. However the defect goes far deeper than a simple coding error.
COMMENTARY 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? Sometime in the not to distant future there will be a major catastrophe related to insecure Internet software. Perhaps a major bank will go broke, perhaps the stock market will be manipulated, I'm not sure about the specifics but it will happen. There will be a congressional hearing and they will ask why such a dangerous language as C was choosen. How will the industry answer that? Shortly after that software manufactuers will be held liable for security flaws if they can't show that they used safe techniques and safe languages. C will not be considered safe and using it will open you up to serious liability. You ask, "When will we learn? When?". The answer is, "Soon." -- ======================================================================= Life is short. | Craig Spannring Ski hard, Bike fast. | cts () internetcds com --------------------------------+------------------------------------ Any sufficiently perverted technology is indistinguishable from Perl. =======================================================================
Current thread:
- EMERGENCY: new remote root exploit in UW imapd Anonymous (Jul 16)
- Re: EMERGENCY: new remote root exploit in UW imapd Craig Spannring (Jul 16)
- Re: EMERGENCY: new remote root exploit in UW imapd Perry E. Metzger (Jul 16)
- Writing safe code: Java? (was: Re: EMERGENCY: new remote root Art Werschulz (Jul 21)
- Re: EMERGENCY: new remote root exploit in UW imapd Alec Kosky (Jul 16)
- Re: EMERGENCY: new remote root exploit in UW imapd Kragen (Jul 17)
- Buffer overflows. was Re: EMERGENCY: new remote root exploit in Craig Spannring (Jul 17)
- Re: Buffer overflows. was Re: EMERGENCY: new remote root exploit Geoffrey KEATING (Jul 19)
- Re: EMERGENCY: new remote root exploit in UW imapd FanLi Tai (Jul 18)
- Re: EMERGENCY: new remote root exploit in UW imapd Brett Lymn (Jul 19)
- Re: EMERGENCY: new remote root exploit in UW imapd Perry E. Metzger (Jul 16)
- SECURITY: imap-4.1.final now available twiztah (Jul 16)
- Verity/Search'97 Security Problems Jay Soffian (Jul 16)
(Thread continues...)
- Re: EMERGENCY: new remote root exploit in UW imapd Craig Spannring (Jul 16)