Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!mstar!mstar.morningstar.com!bob From: bob@MorningStar.Com (Bob Sutterfield) Newsgroups: alt.hackers Subject: Re: Computer Abuse / Product Liability / Criminal Statutes / ECPA Message-ID: Date: 17 Jan 90 14:09:59 GMT References: <22359@usc.edu> Sender: news@MorningStar.COM (USENET Administrator) Reply-To: bob@MorningStar.Com (Bob Sutterfield) Organization: Morning Star Technologies Lines: 84 Approved: why bother? In-reply-to: blackcat@neuro.usc.edu's message of 17 Jan 90 05:58:27 GMT In article <22359@usc.edu> blackcat@neuro.usc.edu writes: One sorry bugger to date has introduced a virus that managed to utilize a little known defect in DEC and SUN system software ... The defect is present in all such software derived from the same BSD sources. DEC and Sun had nothing more to do with it than any other manufacturer shipping their own versions of that software, except that the worm's perpetrator had access to DEC and Sun hardware. Had {s}he access to other hardware, likely other brands of machines would have fallen victim as well. ...I would note that his effort (the INTERNET virus) meets each of the criteria discussed so far in this group for being a "hack" of the highest level ... one requiring a considerable degree of expertise ... and one (from personal examination of virus code) which was not readily understood by an experienced hacker. (How do you know that it's "his" effort and not "her" effort?) From other accounts, the worm was a poor-quality piece of code. It was inelegantly written and didn't take advantage of several pieces of information that were available to it, that would have made it much more prolific. It used inefficient algorithms in several spots, and contained bugs that rendered important parts of its apparently- intended functions impotent. The perpetrator showed some rudimentary awareness of some particular features of the systems it attacked, but not an astute understanding of computer science nor an overall knowledge of the systems it attacked. In other words, yes, a "hack" of the highest level, not a quality piece of work that I would have been proud to put my name on. The attacker should *not* be lauded for any expertise displayed. FINAL COMMENT: The INTERNET virus should be treated as a product liability question. In my opinion, DEC and SUN should pay the cost of the cleanup effort. If it were not for latent defects in the products distributed by these two manufacturers (which have been subsequently repaired by emergency hacks and official patches), the relatively innocuous INTERNET virus could not have spread so far so rapidly. As noted above, other manufacturers' products contained the same holes, and some still might. No particular ones should bear any particular liability beyond that of any others, just because their machines were the ones that happened to be available for the attacker's development work. ...today's vendors are incapable of producing computer products without significant security (and for that mater day to day operational) defects... we are going to have to find a better way to secure systems ... than the Morris show trial. Agreed. Such efforts are underway, most notably the Computer Emergency Response Team. Channels are being put in place between Internet workers and those responsible for host software, or at least those responsible parties who are interested in being made aware of the problems with their software. Obligatory hack story: a late computer graphics production company had designed and built their own custom fast 32-bit Unibus frame buffers, with eight bits each for red, green, and blue and eight bits for "coverage", an antialiasing technique (read some papers from probably ten years ago by Frank Crow and Charles Csuri). Some Sun-1 workstations were purchased as artistic workbenches, and needed the capability to preview images using the same rendering software as was running on the larger machines. At the time, the only commercially available frame buffers that were even vaguely appropriate provided only eight bits per pixel. So I bought three video boards (all the poor desktop Sun could hold in its little Multibus without overheating, and even that was iffy) and took red from one, green from another, and blue from the third. The boards were mapped into Multibus address space, and coverage was implemented in a big malloc()'d hunk of the Sun's own scarce core. A collection of twenty-line macros implemented my emulation of the system call interface to the Unibus device drivers, and the rendering software (once realigned for proper byte-ordering non-assumptions) never knew the difference. It certainly didn't know that it was talking to three separate devices plus an in-core buffer. Once scaled for host CPU speed, my hack compared well with the performance of the custom logic. Management was pleased, but the boards' designer wasn't exactly ecstatic at me :-)