From owner-freebsd-security Thu Jul 16 17:39:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA24693 for freebsd-security-outgoing; Thu, 16 Jul 1998 17:39:05 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from bangkok.office.cdsnet.net (bangkok.office.cdsnet.net [204.118.245.23]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA24688 for ; Thu, 16 Jul 1998 17:38:55 -0700 (PDT) (envelope-from cts@bangkok.office.cdsnet.net) Received: (from cts@localhost) by bangkok.office.cdsnet.net (8.8.8/8.8.5) id RAA05041; Thu, 16 Jul 1998 17:35:04 -0700 (PDT) Date: Thu, 16 Jul 1998 17:35:04 -0700 (PDT) Message-Id: <199807170035.RAA05041@bangkok.office.cdsnet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Craig Spannring To: Anonymous Cc: bugtraq@netspace.org, cert@cert.org, freebsd-security@FreeBSD.ORG, security@bsdi.com Subject: Re: EMERGENCY: new remote root exploit in UW imapd In-Reply-To: <199807162206.AAA30072@basement.replay.com> References: <199807162206.AAA30072@basement.replay.com> X-Mailer: VM 6.31 under Emacs 20.2.1 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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. ======================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message