eli@spdcc.COM (Steve Elias) (11/07/88)
"Wormer" Morris has quite a career ahead of him, i'll bet. he has done us all a favor by benevolently bashing bsd 'security'. the smtp/sendmail security hole that he exploited was big enough to drive the Whirlwhind computer through -- never mind a few thousand Suns & bsd vaxes. the hole was so obvious that i surmise that Morris was not the only one to discover it. perhaps other less reproductively minded arpanetters have been having a field 'day' ever since this bsd release happened. some of the more security minded folk out there might have archived ps records which could indicate the presence of spurious shells spawned from smtp. depending on how long Mr. Morris used the security hole, he may be very well qualified to tell all whether he saw signs of other creative use of the sendmail security gift. in at least one sense, Morris has done a service for the internet. nobody will be able to continue to "benefit" from the bsd/sysV sendmail -- which was the true trojan horse. -- harvard!spdcc!eli
vixie@decwrl.dec.com (Paul Vixie) (11/07/88)
# the hole [in sendmail] was so obvious that i surmise that Morris # was not the only one to discover it. perhaps other less # reproductively minded arpanetters have been having a field # 'day' ever since this bsd release happened. I've known about it for a long time. I thought it was common knowledge and that the Internet was just a darned polite place. (I think it _was_ common knowledge among the people who like to diddle the sendmail source.) The bug in fingerd was a big surprise, though. Overwriting a stack frame on a remote machine with executable code is One Very Neat Trick. -- Paul Vixie Work: vixie@decwrl.dec.com decwrl!vixie +1 415 853 6600 Play: paul@vixie.sf.ca.us vixie!paul +1 415 864 7013
BILLW@MATHOM.CISCO.COM (William Westfield) (11/07/88)
This has been the second major trojan horse in sendmail. I think the people working on the code should put a lot more thought into including code that can cause such serious security holes EVER, in addition to trying to make sure that test code is not propagated into "production" environments. It isn't obvious to me that being able to send mail to commands is particurally useful even in a debugging environment. Bill Westfield cisco Systems. -------
jbn@glacier.STANFORD.EDU (John B. Nagle) (11/07/88)
In article <24@jove.dec.com> vixie@decwrl.dec.com (Paul Vixie) writes: >The bug in fingerd was a big surprise, though. Overwriting a stack frame >on a remote machine with executable code is One Very Neat Trick. Yes. But not all that uncommon, given classical C's rather casual approach to array sizing. "login" in V6 UNIX could be broken by submitting very long, suitably constructed passwords. John Nagle
john@anasaz.UUCP (John Moore) (11/07/88)
In article <24@jove.dec.com> vixie@decwrl.dec.com (Paul Vixie) writes: ># the hole [in sendmail] was so obvious that i surmise that Morris According to press reports, RM spent his summers working at AT&T on "Unix Communications Software Security". Anyone with a source license check to see if he slipped a trojan horse into uucico or uuxqt or something? -- John Moore (NJ7E) {decvax, ncar, ihnp4}!noao!nud!anasaz!john (602) 861-7607 (day or eve) {gatech, ames, rutgers}!ncar!... The opinions expressed here are obviously not mine, so they must be someone else's. :-)
ferencz@cwsys3..CWRU.Edu (Don Ferencz) (11/07/88)
In article <24@jove.dec.com> vixie@decwrl.dec.com (Paul Vixie) writes: > >I've known about it for a long time. I thought it was common knowledge >and that the Internet was just a darned polite place. (I think it _was_ >common knowledge among the people who like to diddle the sendmail source.) > >The bug in fingerd was a big surprise, though. Overwriting a stack frame >on a remote machine with executable code is One Very Neat Trick. I wasn't aware of these tricks, but I find them interesting now, knowing what security hazards they pose. Is there some place interested [sick, twisted] individuals like me could get more information on Morris' handiwork? It would be a benefit from a security aspect. I also realize that presenting such information could be considered another risk, perhaps "inviting" someone else to subject us to the same peril (although most of the net is now "immunized" against this particular virus). =========================================================================== | Don Ferencz | "And in the end/ | | ferencz@cwsys3.cwru.EDU | The love you take/ | | Department of Systems Engineering | Is equal to the love you make." | | Case Western Reserve University | -- The Beatles | ===========================================================================
dre%ember@Sun.COM (David Emberson) (11/08/88)
In article <2060@spdcc.COM>, eli@spdcc.COM (Steve Elias) writes: > "Wormer" Morris has quite a career ahead of him, i'll bet. > he has done us all a favor by benevolently bashing bsd 'security'. > I knew about this sendmail bug at least four years ago, courtesy of Matt Bishop (now at Dartmouth). He wrote a paper detailing at least a half dozen holes in the Unix system and methods for constructing trojan horses which was so dangerous that he responsibly decided not to publish it, but instead to give selected copies to people who could fix some of the problems. He also wrote an article for the Usenix newsletter, ;login, which explained how to write secure setuid shell scripts--a major source of security holes. Matt did not "benevolently bash" anyone's machines. His behaviour, while unsung by the press and the Usenet community, is an example of the highest in profession- al and academic standards. This is the kind of behaviour that we should be extolling. It is a pity that the perpetrator of this hack, allegedly Mr. Morris, is now hailed as a famous "expert" in computer security. No doubt he will make a fortune after the noise dies down as a security consultant. In fact, I saw someone quoted in this morning's Wall Street Journal as saying that the perpetrator was someone he would love to hire! Not I! I would think that prison would be a better place for a person who cost the government, several universities, and many companies untold thousands of man-hours and millions of dollars in downtime and effort spent tracking this piece of garbage down. And it is almost certain that all the copies of the virus haven't been found. Unfortunately, the press seems to grab hold of every stupid jerk like this and hail him as some sort of genius. Somehow the issue of computer security evokes images of high school kids firing off MX missles or some other vision which terrifies the public, and the press loves sensation more than substance. A few years ago there was pandemonium in the press when someone told them that terminals with programmable function keys could be trojan-horsed. Big deal! But the media broadcast repeatedly the "revelation" that most terminals in the world had this "bug." Now they are jumping up and down because the recent virus made its way into Lawrence Livermore and NASA Ames--even though it didn't make it into any classified machines. The news people are more interested in irresponsibly stirring people into a frenzy than they are in responsible reporting of facts. I call upon my fellow computing professionals to promote ethical behaviour amongst their students and colleagues and to denounce destructive misuse of computing knowledge. I also call upon them to refuse to participate in the glorification of people in the profession who engage in this kind of behaviour. We must police ourselves and censure those amongst us who engage in this type of computer crime. Much is at risk if hysterical reporters cause hysterical law makers to place restrictions on networks, on the capability of hardware, on access to computing facilities, or on software. Computer security costs a great deal of money, like defense spending. I for one would rather see this money go for better things. Dave Emberson (dre@sun.com)
eli@spdcc.COM (Steve Elias) (11/08/88)
In article <76424@sun.uucp> dre%ember@Sun.COM (David Emberson) writes: >In article <2060@spdcc.COM>, eli@spdcc.COM (Steve Elias) writes: >> "Wormer" Morris has quite a career ahead of him, i'll bet. >> he has done us all a favor by benevolently bashing bsd 'security'. > >prison would be a better place for a person who cost the government, several >universities, and many companies untold thousands of man-hours and millions of >dollars in downtime and effort spent tracking this piece of garbage down. And >it is almost certain that all the copies of the virus haven't been found. my opinion is that it is almost certain that others have been using such security holes in unix for quite some time. i'm glad to see such gaping security holes closed; it is too bad that it took a USA Today Worm Program to do this. ca va. >Unfortunately, the press seems to grab hold of every stupid jerk like this and >hail him as some sort of genius. Morris is apparently quite intelligent. but he's also apparently a jerk enough to let his worm get away. we may be lucky that it escaped (or was released) before he had a chance to slow its propagation speed such that it would be more difficult to notice... or worse. -- harvard!spdcc!eli
jbn@glacier.STANFORD.EDU (John B. Nagle) (11/08/88)
>According to press reports, RM spent his summers working at AT&T >on "Unix Communications Software Security". Anyone with a source >license check to see if he slipped a trojan horse into uucico >or uuxqt or something? This is serious. The knowledge that this person had the opportunity to tamper with the master source code for UNIX is very worrisome. A major examination of all AT&T-provided security related code is in order. We may not be at the end of this yet. John Nagle
avr@mtgzz.att.com (a.v.reed) (11/09/88)
In article <76424@sun.uucp>, dre%ember@Sun.COM (David Emberson) writes: < In article <2060@spdcc.COM>, eli@spdcc.COM (Steve Elias) writes: < > "Wormer" Morris has quite a career ahead of him, i'll bet. < > he has done us all a favor by benevolently bashing bsd 'security'. < < I knew about this sendmail bug at least four years ago, courtesy of Matt < Bishop (now at Dartmouth). He wrote a paper detailing at least a half dozen < holes in the Unix system and methods for constructing trojan horses which was < so dangerous that he responsibly decided not to publish it, but instead to < give selected copies to people who could fix some of the problems. He also < wrote an article for the Usenix newsletter, ;login, which explained how to < write secure setuid shell scripts--a major source of security holes. Matt did < not "benevolently bash" anyone's machines. His behaviour, while unsung by < the press and the Usenet community, is an example of the highest in profession- < al and academic standards. This is the kind of behaviour that we should be < extolling. Really? In my book, a key component of professionalism is "owning the problem". That means you work it until it gets fixed. "Giving selected copies to people who could fix some of the problems" (they didn't) is not enough. Morris did what was necessary to get the problems fixed. For that, many of us are grateful. And yes, some of us LIKE people who "own the problem" until it is solved. Adam Reed (avr@mtgzz.ATT.COM)
morgan@polya.Stanford.EDU (Robert L. Morgan) (11/09/88)
I could only sigh as I telnet'ed to the various machines that I use here on campus to change my passwords last Friday morning (along with most other users, no doubt), hoping that some "bored graduate student" wasn't sucking up the cleartext passwords as they passed across our various braodcast LANs. The recent viral event makes it very clear that those of us who promote the use of network-attached computers in their current insecure state are on the same moral ground with, say, the automotive engineers and management who manufactured and sold the exploding Pintos of a few years back. There is a conspiracy of silence (acknowledged by those posters who "knew about the bug four years ago") that we all participate in whenever we design, produce, purchase, or install such systems without raising the issue of security. Project Athena (among others) has shown that order-of-magnitude improvements in security are possible without terrible penalties in performance or usability, but is anyone listening? I hope people will keep the implications of the virus attack in mind as they go about their daily technological work. A patch to sendmail, putting Mr. Morris in jail, or saying the Pledge of Allegiance each morning, are not the answer. - RL "Bob" Morgan Networking Systems Stanford
dudek@frapray.ksr.com (Glen Dudek) (11/09/88)
In article <1445@anasaz.UUCP> john@anasaz.UUCP (John Moore) writes: >In article <24@jove.dec.com> vixie@decwrl.dec.com (Paul Vixie) writes: >># the hole [in sendmail] was so obvious that i surmise that Morris > >According to press reports, RM spent his summers working at AT&T >on "Unix Communications Software Security". Anyone with a source >license check to see if he slipped a trojan horse into uucico >or uuxqt or something? I was system administrator at Harvard's computer science computing facility while Robert Morris was an undergraduate there. I found him to be an intelligent and responsible person. He volunteered his assistance in solving difficult problems in network configuration and routing, and helped to make Harvard a major Northeast news and mail gateway. He did not exploit his knowledge of UNIX security deficiencies to break into systems or install trojan horses, though he well could have. I do think that if he did indeed release this worm, he showed extraordinarily poor judgement. However, I would not consider it justice to punish him as a criminal. I am convinced he had no malicious intent (please, no arguing about intent and breaking the law - I am talking about justice, not the law). I do not think the world need worry about holes that Robert Morris could have created - I think we need to worry about the ones he didn't find. Glen Dudek ex-postmaster@harvard.harvard.edu
matt@oddjob.uchicago.edu (Matt Crawford) (11/09/88)
In article <76424@sun.uucp>, dre%ember.sun.com (David Emberson) writes:
) I knew about this sendmail bug at least four years ago, courtesy of Matt
) Bishop (now at Dartmouth). ... His behaviour, while unsung by
) the press and the Usenet community, is an example of the highest in
) professional and academic standards.
How long have you been at sun? Or how long has anyone at sun known of
the debug hole? And yet they kept shipping binaries with the hole open.
This is an example of the lowest in conscientious responsibility to the
customer.
Matt Crawfordalb@notecnirp.Princeton.EDU (Adam L. Buchsbaum) (11/09/88)
In article <17823@glacier.STANFORD.EDU> jbn@glacier.UUCP (John B. Nagle) writes: > This is serious. The knowledge that this person had the opportunity to >tamper with the master source code for UNIX is very worrisome. A major >examination of all AT&T-provided security related code is in order. > > We may not be at the end of this yet. > > John Nagle Personally, I'd be much more concerned with software that was written by people who have been clever enough to have not yet been caught...
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (11/09/88)
In article <17823@glacier.STANFORD.EDU> jbn@glacier.UUCP (John B. Nagle) writes: > This is serious. The knowledge that this person had the opportunity to >tamper with the master source code for UNIX is very worrisome. A major >examination of all AT&T-provided security related code is in order. Not just security related code - but ALL code. A trojan horse in awk or sed would be just as deadly. I'm casting my vote with some other poster who suggested taking a fine toothed comb to all the UUCP code. Meanwhile, I'm working on a replacement login so I can have a shadow password file on this machine. -- John F. Haugh II +----Make believe quote of the week---- VoiceNet: (214) 250-3311 Data: -6272 | Nancy Reagan on Artifical Trish: InterNet: jfh@rpp386.Dallas.TX.US | "Just say `No, Honey'" UucpNet : <backbone>!killer!rpp386!jfh +--------------------------------------
seibel@cgl.ucsf.edu (George Seibel) (11/09/88)
In article <76424@sun.uucp> dre%ember@Sun.COM (David Emberson) writes: >In article <2060@spdcc.COM>, eli@spdcc.COM (Steve Elias) writes: >> "Wormer" Morris has quite a career ahead of him, i'll bet. >> he has done us all a favor by benevolently bashing bsd 'security'. >I knew about this sendmail bug at least four years ago, courtesy of Matt >Bishop (now at Dartmouth). He wrote a paper detailing at least a half dozen >holes in the Unix system and methods for constructing trojan horses which was >so dangerous that he responsibly decided not to publish it, but instead to >give selected copies to people who could fix some of the problems. He also >wrote an article for the Usenix newsletter, ;login, which explained how to >write secure setuid shell scripts--a major source of security holes. Matt did >not "benevolently bash" anyone's machines. His behaviour, while unsung by >the press and the Usenet community, is an example of the highest in profession- >al and academic standards. This is the kind of behaviour that we should be >extolling. In all due respect, why? It didn't seem to be very effective in closing the hole in sendmail. Now that everyone is coming out of the woodwork exclaiming that they've known about this bug for years, I can't help but wonder why it wasn't fixed. There were a lot of people running around a couple of weeks ago under the blissful assumption that their computers were reasonably secure - they had done all the "right" things, vis a vis file protections, setuid scripts and the like, and all the while, *anyone* with the appropriate knowledge (and apparently a lot of people had it) could have done *anything* they wanted to your machine! Perhaps that was no great surprise to many readers of this newsgroup. Fine. If that's the way people want it, then let's be up front and print a warning on each copy of system software that ships: "Congratulations! You just bought a fine copy of Unix. Don't keep any files you care about on it." If we have security holes on our machines that are well known, and we do nothing to patch those holes, we are asking for trouble. George Seibel
seibel@cgl.ucsf.edu (George Seibel%Kollman) (11/09/88)
In article <11226@cgl.ucsf.EDU> I write: >file protections, setuid scripts and the like, and all the while, *anyone* >with the appropriate knowledge (and apparently a lot of people had it) >could have done *anything* they wanted to your machine! Oops.. not *anything*, perhaps *some* things... the sendmail bug doesn't provide root access; more likely 'daemon' or something of that sort. One of our local hosts did have the root password cracked in the recent worm attack, but that was due to poor choice of root password rather than any of the myriad *other* security holes we learned about courtesy of Mr. Morris. My appologies for the misinformation. George Seibel
folta@tove.umd.edu (Wayne Folta) (11/09/88)
In article <389@ksr.UUCP> dudek@ksr.com (Glen Dudek) writes: > >I was system administrator at Harvard's computer science computing >facility while Robert Morris was an undergraduate there. I found him >to be an intelligent and responsible person. He volunteered his >assistance in solving difficult problems in network configuration and >routing, and helped to make Harvard a major Northeast news and mail >gateway. He did not exploit his knowledge of UNIX security >deficiencies to break into systems or install trojan horses, though he >well could have. > Is anyone sure that Morris didn't plant any trojan horses at Harvard? From the popular press accounts (admittedly the popular press is naive and sensationalist) Morris had passwords recorded in his account for machines at MIT and Harvard. Is this so? If so, why did he have them? If so, did his buddies at Harvard give them to him, or did he steal them? I am sure that Glen Dudek speaks with authority about Morris' helpfulness, intelligence, and general good nature. But how can he authoritatively state that Morris did not compromise Harvard's systems? Wayne Folta (folta@tove.umd.edu 128.8.128.42)
folta@tove.umd.edu (Wayne Folta) (11/09/88)
This is a very difficult case. If Good Morris is let off because he is sincere and meant no harm, what about the 2000 Evil Morrises that lurk in every high school and university in the land? The next guy could claim that his destructive program was not meant to be destructive, that he (or she) only meant to overwrite the systems' message of the day, and a bug resulted in destroying a filesystem. (Morris is like a crime buff who, to prove that it can be done, smuggles a gun onto a plane and hijacks it to Canada. He has shown a problem in the system, but he has created the defense for every would-be hijacker in America.) And remember, at least two of the well-known Macintosh viruses were not meant to harm anyone's system, but unexpected side-effects caused crashes. Morris' program wasn't meant to get loose, but it did. It wasn't meant to destroy data but... Wayne Folta (folta@tove.umd.edu 128.8.128.42)
ekrell@hector.UUCP (Eduardo Krell) (11/10/88)
In article <17823@glacier.STANFORD.EDU> jbn@glacier.UUCP (John B. Nagle) writes: > This is serious. The knowledge that this person had the opportunity to >tamper with the master source code for UNIX is very worrisome. A major >examination of all AT&T-provided security related code is in order. This is nonsense. He worked at the research center in Murray Hill, which has nothing to do with the organization in charge of the official System V distribution in Summit, NJ. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com
jqj@HOGG.CC.UOREGON.EDU (11/10/88)
Date: 7 Nov 88 20:06:23 GMT From: dre@sun.com Subject: Re: a holiday gift from Robert "wormer" Morris To: tcp-ip@sri-nic.arpa Message-Id: <76424@sun.uucp> I knew about this sendmail bug at least four years ago, courtesy of Matt Bishop (now at Dartmouth). He wrote a paper detailing at least a half dozen holes in the Unix system and methods for constructing trojan horses which was so dangerous that he responsibly decided not to publish it, but instead to give selected copies to people who could fix some of the problems. This raises another interesting question: what is the responsibility of the major Unix vendors vis. such network security problems? If these security holes have in fact been known by people in SUN and DEC (not to mention Berkeley) for years, why weren't they fixed? I believe that the ONLY way we are going to see most of these Unix security problems resolved is to beat on the vendors to fix them in their next releases. We are being totally irresponsible if we use the Unix from vendor X, know about a major security hole in X's Unix, and don't SPR it. X is being totally irresponsible if they don't fix problems SPRed, and quite irresponsible not to be fixing problems that are "common knowledge". A test: will the next releases of SunOS and Ultrix include - a sendmail without the "debug" bug - a fixed fingerd - a fixed ftpd ...etc.?
bill@UHCCUX.UHCC.HAWAII.EDU (William J. King) (11/10/88)
Perhaps the Computer Science programs should:
1. require students to take ethics, humanities and social science
courses.
2. restructure their programs such the early years are not simply
set up to flunk out all but the 'compulsive' hackers. Fortunately
these programs do NOT succeed, and ' a few good men & women' get by.
Furthermore:
3. lets not celebrate movies such as 'War Games' where the hacker kid
breaks the law numerous times AND gets off.
4. Lets engineer better operating systems!
5. More distribution of binary systems and less source code.
hutch@net1.ucsd.edu (Jim Hutchison) (11/10/88)
In <11226@cgl.ucsf.EDU> seibel@hegel.mmwb.ucsf.edu.UUCP (George Seibel) writes: > [...] If that's >the way people want it, then let's be up front and print a warning on >each copy of system software that ships: "Congratulations! You just >bought a fine copy of Unix. Don't keep any files you care about on it." You would prefer VMS where you can read the documentation to find out how to break security? Or how about a system with no features? If you boadcast a bug, and its fix/patch, you take responsibility for that patch. You also risk letting loose all sorts of mayhem on systems where the system manager is lazy or on vacation. Binary sites are particularly limited in the number of fixes they can apply. So out go the fixes quietly, and perhaps only locally. Here we are. Do you have a good answer, or are you just going to indulge yourself in a good screaming fit? >If we have security holes on our machines that are well known, and we >do nothing to patch those holes, we are asking for trouble. True. But not real. Many people spend a great part of their waking hours monitoring and fixing the system, locally and for others. Don't be viscious and ignore their hard work. >George Seibel /* Jim Hutchison UUCP: {dcdwest,ucbvax}!cs!net1!hutch ARPA: JHutchison@ucsd.edu These are my opinions, and now you have your perceptions of them. */
smb@ulysses.homer.nj.att.com (Steven M. Bellovin) (11/10/88)
> According to press reports, RM spent his summers working at AT&T > on "Unix Communications Software Security". Anyone with a source > license check to see if he slipped a trojan horse into uucico > or uuxqt or something? Morris wrote an entirely new version of uucp, one that a higher degree of inherent security than any of its predecessors. It was in fact installed as the production uucp on a number of research machines for several years. Ultimately, it was supplanted by Honey DanBer uucp because it wasn't hardened enough against real-world failures. At Morris's request, I went over the code in great detail; there were no holes visible -- and I repeat, I studied his code thoroughly. In any event, to the best of my knowledge that version of uucp was never released. --Steve Bellovin
andrew@alice.UUCP (Andrew Hume) (11/11/88)
In article <17823@glacier.STANFORD.EDU>, jbn@glacier.STANFORD.EDU (John B. Nagle) writes: > >According to press reports, RM spent his summers working at AT&T > >on "Unix Communications Software Security". Anyone with a source > >license check to see if he slipped a trojan horse into uucico > >or uuxqt or something? > > This is serious. The knowledge that this person had the opportunity to > tamper with the master source code for UNIX is very worrisome. A major > examination of all AT&T-provided security related code is in order. > > We may not be at the end of this yet. > > > John Nagle come on. this is so prepostrous that i feel obliged to respond. morris has never worked on System V code which is probably what you mean by the master source. he has worked on Research Unix but given Ken Thompson used his Turing Award lecture to advertise a trojan horse he put into research unix; you would have to be very naive to trust research unix. (although there are currently no known trojan horses or viruses.) more importantly, morris has been doing this in an open way; penetrating systems from the outside, not via trojan horses. in a peculiar (but obvious to me) way, he is doing the honourable thing; attacking systems via their own foibles, and not ones he has added. and we have heard peter honeyman acknowledge morris's contribution towards the current uucp. so think a little before raising panics and denigrating people's character.
mrd@sun.soe.clarkson.edu (Michael DeCorte) (11/14/88)
Think of the fun everyone is going to have when the politicians and lawers start chewing on this. Especially any of them who read CACM. Can you say regulation? -- Michael DeCorte // (315)265-2439 // P.O. Box 652, Potsdam, NY 13676 Internet: mrd@sun.soe.clarkson.edu // Bitnet: mrd@clutx.bitnet --------------------------------------------------------------------------- Clarkson Archive Server // commands = help, index, send, path archive-server@sun.soe.clarkson.edu archive-server%sun.soe.clarkson.edu@omnigate.bitnet dumb1!dumb2!dumb3!smart!sun.soe.clarkson.edu!archive-server ---------------------------------------------------------------------------
dre%ember@Sun.COM (David Emberson) (11/15/88)
I wish to clarify my recent statement that I knew about this security hole in sendmail. Apparently some people have taken this to mean that Sun Microsystems knew about a problem in their software and deliberately shipped a sendmail with a security hole. This is not the case. At the time that Matt Bishop told me of this bug (1984), we were both employed by Megatest Corporation. I ran the computer engineering group there, and Matt was a member of the group. We were a beta site for Berkeley's Unix group. Matt's research interest is in security, and that is how I found out about this bug. It was my understanding that the sendmail trapdoor was reported to Berkeley in 1984 and fixed in 4.3BSD. I have been employed by Sun Microsystems since January of this year. At no time did anyone in the software group know that the sendmail trapdoor could be used to breach security. If the bug had been properly reported, it most certainly would have been fixed. When Sun finally did become aware of the security problems, reaction was swift and effective. I think the work that Chuq Von Rospach did in getting patches through the system in only a few days (through a thorough software QA process) is representative of the kind of responsiveness that Sun strives for and generally provides. Paul Vixie of DEC Western Research Labs also posted a note to this network stating that he knew of the sendmail problem: >From sun!decwrl!vixie Sun Nov 6 11:36:10 1988 >Subject: Re: a holiday gift from Robert "wormer" Morris >Organization: DEC Western Research Lab ># the hole [in sendmail] was so obvious that i surmise that Morris ># was not the only one to discover it. perhaps other less ># reproductively minded arpanetters have been having a field ># 'day' ever since this bsd release happened. > >I've known about it for a long time. I thought it was common knowledge >and that the Internet was just a darned polite place. (I think it _was_ >common knowledge among the people who like to diddle the sendmail source.) > >The bug in fingerd was a big surprise, though. Overwriting a stack frame >on a remote machine with executable code is One Very Neat Trick. >-- >Paul Vixie >Work: vixie@decwrl.dec.com decwrl!vixie +1 415 853 6600 So, I suppose that it is technically true that the knowledge of this problem existed both inside of DEC and Sun, but it was never reported via a formal bug report, so it apparently fell through the cracks at both companies. In my case, I thought the problem no longer existed. So I was very surprised to see this trapdoor exploited by the worm. It did not seem to me like I was impugning the quality of anyone's work to say, "Oh yeah. I knew about that." I did not think it necessary to say that my statements are not official statements of Sun Microsystems, Inc. I thought that was obvious. In any case, I sincerely apologize to the very fine team in Sun's software group for this misunderstanding. Dave Emberson (dre@sun.com)
pavlov@hscfvax.harvard.edu (G.Pavlov) (11/16/88)
In article <77604@sun.uucp>, dre%ember@Sun.COM (David Emberson) writes: > > So, I suppose that it is technically true that the knowledge of this problem > existed both inside of DEC and Sun, but it was never reported via a formal > bug report, so it apparently fell through the cracks at both companies. Note that DEC claims to have closed the door (before the worm). As far as I know, Vaxen running Ultrix did ok. greg pavlov, fstrf, amherst, ny
cmf@cisunx.UUCP (Carl M. Fongheiser) (11/17/88)
In article <666@hscfvax.harvard.edu> pavlov@hscfvax.harvard.edu (G.Pavlov) writes: > Note that DEC claims to have closed the door (before the worm). As far as > I know, Vaxen running Ultrix did ok. > > greg pavlov, fstrf, amherst, ny That's true, they did. However, there are enough Ultrix machines on the Internet which *don't* use Ultrix sendmail that blanket statements about the safety of Ultrix aren't necessarily trustworthy. Why don't we run Ultrix sendmail? Because currently available releases of Ultrix sendmail don't know how to talk to domain name servers or process MX records. I suspect if you asked a number of other people, they'd give you the same answer. Ultrix 3.0 is supposed to handle that stuff, so maybe this will all mean something in the future. Carl Fongheiser University of Pittsburgh ...!pitt!cisunx!cmf cmf@unix.cis.pittsburgh.edu cmf@pittunix.BITNET
dle@CSL.SRI.COM (David L. Edwards) (11/17/88)
> William J. King <bill@uhccux.uhcc.Hawaii.Edu> writes: > ... > Furthermore: > 3. lets not celebrate movies such as 'War Games' where the hacker kid > breaks the law numerous times AND gets off. > 4. Lets engineer better operating systems! > 5. More distribution of binary systems and less source code. > While I am tired of this topic, I couldn't let this go by without a comment. I agree with 3 & 4 with an emphasis on 4. But distribution of more binary is crazy. Source code was not a real issue in the current virus EXCEPT that the lack of it kept many sites from immediately fixing the problems. A good hacker never needs source to figure out flaws in a design especially when the flaw is as well known as the Sendmail one. All a hacker has to do is come up with a create use for it. -dle
torben@DORSAI.ICS.HAWAII.EDU ("Torben N. Nielsen") (11/17/88)
>Perhaps the Computer Science programs should: > 1. require students to take ethics, humanities and social science > courses. Computer science programs I know of already do that. That's still a part of a college education. > 2. restructure their programs such the early years are not simply > set up to flunk out all but the 'compulsive' hackers. Fortunately > these programs do NOT succeed, and ' a few good men & women' get by. I believe the current tendency is to spend the first few years teaching mostly algorithms and data structures. I'd think that it's hardest for the so-called hackers to make it through the first few years. At least it is if they follow a normal curriculum. >Furthermore: > 3. lets not celebrate movies such as 'War Games' where the hacker kid > breaks the law numerous times AND gets off. Why not? I thought that was a rather delightful movie and if you think about it, it had quite a few *good* points. Besides, all those blinking lights was a nice touch :-) > 4. Lets engineer better operating systems! We are. Look at how we've advanced in functionality. It's not all that surprising that a few holes exist. Actually, I'm more surprised that there haven't been more problems than this. Making a system secure is pretty easy. If you don't mind throwing functionality overboard. Let's learn what can be learned from this incident, fix the holes and go on. Hopefully, vendors and researchers/developers alike will be a little more careful about what they release in the future. > 5. More distribution of binary systems and less source code. I trust you're not serious..... Let's get more source systems out there and then get people to work actively on breaking them. With as much information as possible. That way we might make some real gains. Torben
csd1032@UX.ACSS.UMN.EDU ("Aaron Y. T. Cheung") (11/20/88)
In article <CMM.0.88.595118467.bill@uhccux.uhcc.hawaii.edu> bill@UHCCUX.UHCC.HAW AII.EDU (William J. King) writes: | | 4. Lets engineer better operating systems! better in what sense? is Multics better than Unix? | 5. More distribution of binary systems and less source code. Please justify. For as I see it, binaries are more difficult to patch satisfactorily when problems arise (Murphy's Laws predict so) and that Trojan hourses could creep in more readily, especially regarding distributions in public domain. /* * Aaron Y. T. Cheung */