Interesting, isn't it, that the more things change the more they stay the same. "History teaches us that man does not learn from history" - Santayana (sp?) "Freedom is slavery." George Orwell, 1984 (I think.) "Those who don't know the past are condemned to repeat it in the future." (I don't know who said this.) Well, it took disastrous collapses of bridges to get the field of civil engineering as an accepted and recognised profession with requirements of expertise for its practice. Perhaps this will help for software engineering, but I'm not going to hold my breath. Michael Feldman wrote: > I thought you might be interested in this. > > Mike > > Forwarded message: > > > > The message below is from Risks Digest 19.90 of the comp.risks > > newsgroup. Note particularly the last paragraph. > > > > It's good to see this sort of thing in a very non-Ada forum. > > > > Art > > > > ------------------------------------------------------------------ > > > > Date: Wed, 29 Jul 1998 08:20:52 -0700 (PDT) > > From: Paul Haahr <[log in to unmask]> > > Subject: Long-filename security bug in e-mail readers and safe languages > > > > There's been a lot of coverage of the potential security hole in > > Microsoft and Netscape's mail readers. Most reports note that this is > > the same kind of bug exploited by Robert Morris's Internet worm: > > overflow a fixed-length buffer on the stack to predictably sabotage the > > control flow of the program. > > > > What all the reports I've read appear to be missing is that bugs like > > this are almost inevitable in C or C++, yet pose almost no security > > issues in safer programming languages, including as Java, Lisp, Ada, > > Smalltalk, Modula-3, Eiffel, ML, etc. > > > > That is, the consequence of overflowing an array in Java is that an > > ArrayIndexOutOfBoundsException is thrown. No stack gets overwritten, no > > data gets corrupted. The program fails, but it does so in a sensible, > > predictable manner. Contrast this with C or C++, where the existence of > > a single, unchecked array access based on user-provided input is > > sufficient to expose gaping security holes. > > > > Just as the use of four digits for dates was considered wasteful or > > unnecessary in the past, the use of safe languages is often thought a > > luxury today. It isn't. > > Regards, Bob -- Robert L. Spooner Registered Professional Engineer Research Assistant Intelligent Control Systems Group Applied Research Laboratory Phone: (814) 863-4120 The Pennsylvania State University FAX: (814) 863-7843 P. O. Box 30 State College, PA 16804-0030 [log in to unmask]