WHMurray@DOCKMASTER.ARPA (11/09/89)
Thanks to Jim Frost for a very thought provoking posting. Here are some that I had while reading it. >Limiting Propagation Rates. Simple viruses, and often not-so-simple >ones, will proliferate without bounds. Rampant proliferation will >cause the virus to be noticed early in its lifetime and will probably >lead to its early demise. The internet worm did not do this. Most PC viruses do not do it either. When the vector is a diskette, it need not. Most of the network worms have not done it; they wanted to be noticed. Therefore, the requirement is a function of both the chosen vector and the motive. >Detecting and Avoiding "Virus-Protected" Hosts. I have yet to see a >virus which looked at the state of a system to detect virus detection >mechanisms to nullify them and/or avoid infecting them. Biological viruses simply ignore potential but immune hosts. If the potential population is sufficiently large, the presence of immune subjects is not important. However, again motive is important. We have not seen any viruses that were determined to conceal their existence, in part because writing a virus that no one notices is not any fun. If no one notices, then it is not possible to know about propagation or survival. What fun is that? >Count our blessings now because you >won't believe how bad tomorrow's nightmares will be unless we start >teaching ethics to tomorrow's programmers! I will settle for simple self interest. ALL computer users have a vested interest in an orderly environment in which programs can be relied upon to do only what they advertise. Virus writers are soiling their own nests. William Hugh Murray, Fellow, Information System Security, Ernst & Young 2000 National City Center Cleveland, Ohio 44114 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
krvw@SEI.CMU.EDU (Kenneth R. van Wyk) (11/09/89)
WHMurray@DOCKMASTER.ARPA writes: >> We have not seen any viruses that were determined to conceal their >> existence... In theory anyway, what proof to we have of their non-existence? If they're determined to conceal themselves, then why would we expect to notice them in the first place? In Cliff Stoll's book, "The Cuckoo's Egg", Dr. Stoll points out that for every forty (approximately) computers that the hacker invaded, only one or two system administrators ever noticed. The connections were relatively overt in that they left behind audit trails ('lastlog' entries), yet very few people noticed. (In my personal opinion, by the way, "The Cuckoo's Egg" should be considered required reading by anyone who runs, or is interested in, computers - *highly* recommended.) >> ...in part because writing a virus that no one notices is not any >> fun. If no one notices, then it is not possible to know about >> propagation or survival. What fun is that? There's an important distinction to be made here - detection during propagation vs. detection after (presumably) successful propagation. A virus could well attempt to conceal its existence while propagating, and then do quite the opposite (!) during a destructive phase. No one would notice until it would be too late. I'm not trying to sound like the voice of gloom and doom, really. I don't believe that the sky is falling. The purpose of this posting isn't to sound sensationalistic - merely to raise some questions. Ken van Wyk
frisk@rhi.hi.is (Fridrik Skulason) (11/13/89)
jim frost writes: > Fridrik Skulason writes: > >jim frost writes: > >>Given the limited resources of PC environments, it's > >>unlikely that you'll get a very sophisticated virus. > > >I must disagree. > > No, it's harder. The disagreement results from our different understanding of the words "very sophisticated virus." I understood them in a relative sense, meaning that a "very sophisticated virus" in the PC environment does not have to be nearly as complicated or large as a "very sophisticated virus" in the UNIX environment, and therefore much easier to write. So, we really do not disagree regarding the fact that > MS-DOS systems are so trivial that it's difficult to build a good virus > detector and there are no inherent security systems. Viruses don't need to > be sophisticated. > >"Bypass protection programs and jump directly to the hardware, DOS or > >BIOS routines." > > I didn't add that because that's not usually one of the "survival" > traits, but rather is used in propagation and/or infection. No, because a part of the "survival" is to avoid detection. Many protection program simply hook interrupts, and any virus that bypasses the interrupt table has a good chance of avoiding them altogether. - -frisk
hollombe%sdcsvax@ucsd.edu (The Polymath) (11/15/89)
krvw@SEI.CMU.EDU (Kenneth R. van Wyk) writes: }WHMurray@DOCKMASTER.ARPA writes: } }>> ...in part because writing a virus that no one notices is not any }>> fun. If no one notices, then it is not possible to know about }>> propagation or survival. What fun is that? } }There's an important distinction to be made here - detection during }propagation vs. detection after (presumably) successful propagation. }A virus could well attempt to conceal its existence while propagating, }and then do quite the opposite (!) during a destructive phase. No one }would notice until it would be too late. Here's another scary thought. All the viruses I've heard of so far appear to be the work of malicious amateurs. I can think of motivations that might inspire a professional: An unfriendly government wants to cause dislocation in the United States. It commissions a difficult to detect virus that spends 5 years propagating, then wipes the hard disks of every machine it's on, without warning or explanation. A spy puts out a sophisticated virus that does no damage. It just looks for modems on serial ports and sends what looks like sensitive information to a central collection point. (What sort of information? How about comm program macro files containing account IDs and passwords?) I'm sure you can think of other scenarios. So can "they", whoever "they" are. The Polymath (aka: Jerry Hollombe, hollombe@ttidca.tti.com) Illegitimis non Citicorp(+)TTI Carborundum 3100 Ocean Park Blvd. (213) 452-9191, x2483 Santa Monica, CA 90405 {csun|philabs|psivax}!ttidca!hollombe
hutto@uunet.UU.NET (Jon Hutto) (11/18/89)
In article <0009.8911161700.AA03975@ge.sei.cmu.edu> ttidca.TTI.COM!hollombe%sdc svax@ucsd.edu (The Polymath) writes: >krvw@SEI.CMU.EDU (Kenneth R. van Wyk) writes: >}There's an important distinction to be made here - detection during >}propagation vs. detection after (presumably) successful propagation. >}A virus could well attempt to conceal its existence while propagating, >}and then do quite the opposite (!) during a destructive phase. No one > An unfriendly government wants to cause dislocation in the United > States. It commissions a difficult to detect virus that spends 5 > years propagating, then wipes the hard disks of every machine it's > on, without warning or explanation. This is scary. A Virus writen by someone who knows what they are doing coulsd be very dangerous. Or even one by someone who knows more than viruse writers at any rate. One writen by a non-friendly government would be especaly bad. Forget the cold war, this is the Technical war, between Super computers. We, the users would really be caught between a rock and a hard place. Nothing we could do, but watch them destroy each other. Could you imagine someone who knows IBM-PC ASM well, like Peter Norton, or McAfee writing a virus? (completly hypathetical, no hidden meaning) It would be the worst virus to hit ANYONE. Jon Hutto PC-Tech BBS (214)271-8899 2400 baud USENET: {ames, texbell, rutgers, portal}!attctc!hutto INTERNET: hutto@attctc.dallas.tx.us or attctc!hutto@ames.arc.nasa.gov
christer@cs.umu.se (Christer Ericson) (11/20/89)
levin@BBN.COM (Joel B. Levin) writes: >>I don't agree with you on any of these points, Terry. Say, on the >>Macintosh all calls to ROM are done through trap vectors in RAM. These >>trap vectors are patched by the system file (to fix bugs), by some >>programs and by all anti-virus tools. However, it doesn't take a >>genius to figure out that one could restore the trap vector to it's >>original value and thereby bypassing the "safe" system. . . . >> . . . A patch like this wouldn't occupy much space and is quite >>simple to write. > >Except that when system patches or INIT patches or program patches to >the traps were removed by the virus (and how would the virus decide what >value to restore them to?--this is different for each ROM and system >release version) the user would certainly be likely to notice the >resultant changed program behavior -- or system crashes. > > /JBL First, restoring the traps to their original values isn't that difficult. These are initialized by the ROM, then there must be a table from where all initial values are fetched from, right? As I haven't been writing any viruses lately, I'm not sure if this table is moving around from ROM version to ROM version, but attaining the start address of this table for each and every ROM version isn't too difficult. Also, the virus would of course restore the trap vector after it's done, so why would there be crashes? Actually, it wouldn't even have to change the trap vectors, it could call the ROM directly, but I left that to your imagination to figure out (a fruitless attempt, obviously) since I didn't want to give away freebies to aspirant virus writers. Some things they'll have to figure out themselves. /Christer | Christer Ericson Internet: christer@cs.umu.se | | Department of Computer Science, University of Umea, S-90187 UMEA, Sweden | | >>>>> "I bully sheep. I claim God doesn't exist..." <<<<< |
chrisj@cs.utexas.edu (Chris Johnson) (11/22/89)
christer@cs.umu.se (Christer Ericson) writes: >First, restoring the traps to their original values isn't that >difficult. These are initialized by the ROM, then there must be a >table from where all initial values are fetched from, right? As I >haven't been writing any viruses lately, I'm not sure if this table is >moving around from ROM version to ROM version, but attaining the start >address of this table for each and every ROM version isn't too >difficult. Also, the virus would of course restore the trap vector >after it's done, so why would there be crashes? Actually, it wouldn't There would be crashes because it's very common for software that patches traps to have interdependencies between its patches, i.e. one patch depends on data discovered and stored for later use by another patch. Removing only a portion of such patches will be likely to kill the machine sooner or later. Even if you remove *all* patches, the machine is still in grave danger since the INIT (or whatever did the patching) may have changed some key characteristics of the machine already - characteristics that it's patches would have isolated other software from while they were installed and operating. Further, restoring traps to their original values is going to remove all of the patches put in place by the System itself - the patches that keep that machine running inspite of bugs in the ROMs, etc. Also, whole portions of the OS and Toolbox will be removed by restoring traps to their initial values (as taken from the ROM) - this will kill the machine for sure. And even if you were to take the status of the trap table at some point early in the boot phase (after the key System patches had been made) and restore it much later (just before the first application is loaded, say) you would still be removing portions of the OS since the portions related to MultiFinder are added *after* (not before) all the INITs are loaded. Again, the machine dies for sure. Even if these changes to the trap table are temporary, the same problems inhere - portions of the OS are fully installed and operating while other portions have been partially or completely lobotomized by restoring their trap table entries to some initial value. Provided there were no inter- dependencies between routines in the OS (not to mention the Toolbox) this might not kill the machine immediately (but it would likely kill it event- ually), but since there *are* such interdependencies (often matched only in their importance by their subtlety), the machine is going to die very quickly. Writing well behaved patches is a black art on the best of days - writing the sort of un-patching patches discussed here would make that "black art" look like a carefree romp in the sunlit countryside. I don't think such patches could be implemented safely, and I don't think anyone clever enough to do so would be wasting his time working on viruses in the first place. >even have to change the trap vectors, it could call the ROM directly, >but I left that to your imagination to figure out (a fruitless >attempt, obviously) since I didn't want to give away freebies to >aspirant virus writers. Some things they'll have to figure out >themselves. > >/Christer All in all, I don't think the techniques dealt with in this discussion are significant simply because there are too many reliability and compatibility problems intrinsically linked to them. For what it's worth, - ----Chris (Johnson) - ----Author of Gatekeeper - ----chrisj@emx.utexas.edu
christer@cs.umu.se (11/27/89)
chrisj@cs.utexas.edu (Chris Johnson) writes: >There would be crashes because it's very common for software that >patches traps to have interdependencies between its patches, i.e. one >patch depends on data discovered and stored for later use by another >patch. Removing only a portion of such patches will be likely to kill >the machine sooner or later. > . . . >Further, restoring traps to their original values is going to remove >all of the patches put in place by the System itself - the patches >that keep that machine running inspite of bugs in the ROMs, etc. >Also, whole portions of the OS and Toolbox will be removed by >restoring traps to their initial values (as taken from the ROM) - this >will kill the machine for sure. > . . . So what if I remove system patches? You seem to think that I need to call every little routine in ROM to do my dirty stuff. What I need is say, ChangedResource, WriteResource and perhaps AddResource. What do these traps have to do with OS traps? How many system patches are there for these traps? Do you *really* think that the ROM is truly and utterly worthless without the system patches? Do you think they wrote routines that didn't work at all and then patched them into working? Why would I care if there is some small and obscure bug in the ROM that could make my virus crash with prob. .000001%, after all that is probably the whole idea with the virus after all!! I don't claim that the ROM is bug free, but your indirect claim that every trap is buggy is pretty heavy. (I got that from the "fact" that everything will kill the machine "for sure", in case you wonder). > . . . >Writing well behaved patches is a black art on the best of days - >writing the sort of un-patching patches discussed here would make that >"black art" look like a carefree romp in the sunlit countryside. I >don't think such patches could be implemented safely, and I don't >think anyone clever enough to do so would be wasting his time working >on viruses in the first place. This proves you've missed the point entirely. We're not talking about well behaved viruses here. And just because you think no one would write one isn't exactly proof that no one will... >All in all, I don't think the techniques dealt with in this discussion >are significant simply because there are too many reliability and >compatibility problems intrinsically linked to them. I do think they are significant though. The whole point with my post in the first place was to make people realize that a virus could bypass the protective fences of all anti-viral programs (including Gatekeeper) pretty easily (theoretically anyway). What if a virus changed the resource map directly without going through the ROM at all? We can't just rely on the trivial and obvious protection that Gatekeeper et al. provies. What we need is sophisticated protection schemes, and unless there's no discussion of potential viruses we might never come up with these schemes in time. >- ----Chris (Johnson) /Christer | Christer Ericson Internet: christer@cs.umu.se | | Department of Computer Science, University of Umea, S-90187 UMEA, Sweden | | "Track 0 sector 0 must *always* load into page 8!" -Krakowicz' first law |
chrisj@cs.utexas.edu (Chris Johnson) (11/29/89)
christer@cs.umu.se writes: >chrisj@cs.utexas.edu (Chris Johnson) writes: >>There would be crashes because it's very common for software that >>patches traps to have interdependencies between its patches, i.e. one >>patch depends on data discovered and stored for later use by another >>patch. Removing only a portion of such patches will be likely to kill >>the machine sooner or later. >> . . . >>Further, restoring traps to their original values is going to remove >>all of the patches put in place by the System itself - the patches >>that keep that machine running inspite of bugs in the ROMs, etc. >>Also, whole portions of the OS and Toolbox will be removed by >>restoring traps to their initial values (as taken from the ROM) - this >>will kill the machine for sure. > >So what if I remove system patches? You seem to think that I need to >call every little routine in ROM to do my dirty stuff. What I need is >say, ChangedResource, WriteResource and perhaps AddResource. What do >these traps have to do with OS traps? How many system patches are >there for these traps? Do you *really* think that the ROM is truly >and utterly worthless without the system patches? Do you think they >wrote routines that didn't work at all and then patched them into >working? Why would I care if there is some small and obscure bug in >the ROM that could make my virus crash with prob. .000001%, after all >that is probably the whole idea with the virus after all!! The point is that you can't know the interdependencies of traps. Maybe you can get away with some of what you discuss, but it'll be a matter of luck more than anything else. And *no* I don't think that the ROM is utterly worthless and bug ridden, but most ROMs were created to operate in the context of much earlier system software and may not be (without the patches that would normally be in place) ready to cope with the modern Macintosh. Beyond that, and perhaps more significantly, Apple's fixes to the ROMs are often made not to the routine that has the bug, but to routines invoked *by* that routine which are likely to be, in and of themselves, unrelated to the actual bug. See the ongoing discussion of tail patching in comp.sys.mac.programmer for a full treatment of this subject. So I think the probability is actually a bit greater than ".000001%" that your virus will crash the machine *before* it can replicate itself. At which point it's just not a virus anymore. >I don't claim that the ROM is bug free, but your indirect claim that >every trap is buggy is pretty heavy. (I got that from the "fact" that >everything will kill the machine "for sure", in case you wonder). See above - I certainly didn't mean to claim that everything is buggy. Also, if I can't be sure something will work, when I program, I look at it as a guarantee that sooner or later I'm going to crash somebody's machine. I still make a good number of mistakes (like most folks), but I think this kind of paranoia is a good idea and steers me clear of a lot of other problems. I like to think that all Mac programmers will exercise similar care in their approach to programming issues, but, of course you're right, virus authors may not bother. >>Writing well behaved patches is a black art on the best of days - >>writing the sort of un-patching patches discussed here would make that >>"black art" look like a carefree romp in the sunlit countryside. I >>don't think such patches could be implemented safely, and I don't >>think anyone clever enough to do so would be wasting his time working >>on viruses in the first place. > >This proves you've missed the point entirely. We're not talking about well >behaved viruses here. And just because you think no one would write one isn't >exactly proof that no one will... I didn't miss any point completely. The first of my points which you quote above deals with issue of reliability and practicality - I stand by that statement. The second of those points was a psychological one, it was *not* offered as *proof* of anything, just a statement of what I believe to be a reasonable opinion. If you have a different opinion - that's fine. I hope you and your opinion are very happy together. :-) >>All in all, I don't think the techniques dealt with in this discussion >>are significant simply because there are too many reliability and >>compatibility problems intrinsically linked to them. > >I do think they are significant though. The whole point with my post in the >first place was to make people realize that a virus could bypass the >protective fences of all anti-viral programs (including Gatekeeper) pretty >easily (theoretically anyway). What if a virus changed the resource map >directly without going through the ROM at all? We can't just rely on the >trivial and obvious protection that Gatekeeper et al. provies. For the reasons I stated above, I still don't think the techniques dealt with in this discussion are significant. This is not to say that there aren't ways around the various virus protection schemes currently available - there is not now, nor do I believe that there is ever likely to be, an infallible anti-virus system for the Macintosh. Nonetheless, I don't think that these particular techniques will be of service to anyone in trying to get around anti-virus systems. Since the failed attempts to create such a virus could, however, cause a few victims a lot of damage I thought it was important to comment on the practicality of these techniques. Techniques that would safely create more sophisticated viruses, are techniques that I refuse to comment on in any public forum. (In general I also refuse to comment on the techniques that won't work, but I made a rare exception in this case.) As an aside, Gatekeeper is more sophisticated than Vaccine, and SAM is more sophisticated than Gatekeeper (although in ways that aren't yet important, I'm relieved to say). Gatekeeper is improving and will continue to do so - I will not be advertising these improvements because I do not care to notify would-be virus authors of what Gatekeeper can and cannot do. The more they're left guessing, the better-off the rest of us will be. Further, Gatekeeper, at least, can only be extended so fast because my resources (free time, money, etc.) are very limited. To the extent that this discussion promotes the creation of newer, more sophisticated viruses we are all done a dis-service - I can only extend my tools so fast; if you deprive me of time by accelerating the development of new viruses, you are *not* promoting the creation of more sophisticated anti-virus tools, instead you're hindering such efforts. If you find the protections offered by Vaccine, Gatekeeper and SAM trivial, I would encourage you to write a better tool. I imagine that a lot of people would be very pleased to see another good tool made available. >What we need >is sophisticated protection schemes, and unless there's no discussion of >potential viruses we might never come up with these schemes in time. More to the point, I believe, would be the following statement: "unless we keep up open discussions of this kind the virus authors may never come up with the ways to bypass the existing protection mechanisms." Sharing of information is great, but offering would-be virus authors important information isn't. It'll be a dark victory indeed if we get the more sophisticated anti-virus tools you desire (quite appropriately) IN RESPONSE TO the appearance of more sophisticated viruses made possible by these discussions. I am sympathetic with the desire for more sophisticated tools (although I think you underestimate SAM), but I don't believe that this is the way to make them a reality. If you'd like to pursue these issues privately, I'd welcome an email discussion with you. Seriously. Best wishes, - ----Chris (Johnson) - ----Author of Gatekeeper - ----chrisj@emx.utexas.edu