home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / org / eff / talk / 8162 < prev    next >
Encoding:
Internet Message Format  |  1992-12-29  |  3.2 KB
  1. Path: sparky!uunet!gatech!destroyer!gumby!yale!hsdndev!news.cs.umb.edu!betsys
  2. From: betsys@cs.umb.edu (Elizabeth Schwartz)
  3. Newsgroups: comp.org.eff.talk
  4. Subject: Re: Virus design
  5. Message-ID: <BETSYS.92Dec29144112@ra.cs.umb.edu>
  6. Date: 29 Dec 92 19:41:12 GMT
  7. References: <BETSYS.92Dec27120852@ra.cs.umb.edu> <ousHwB1w165w@ruth.UUCP>
  8. Sender: news@cs.umb.edu (USENET News System)
  9. Organization: University of Massachusetts at Boston
  10. Lines: 50
  11. In-Reply-To: rat@ruth.UUCP's message of 28 Dec 92 12: 35:59 GMT
  12. Nntp-Posting-Host: ra.cs.umb.edu
  13.  
  14. In article <ousHwB1w165w@ruth.UUCP> rat@ruth.UUCP (David Douthitt) writes:
  15.  
  16. >What about a virus that showed up on your system, and said "Hi!  I used
  17. >security hole x, but I fixed it!"  Imagine what would have happened
  18. >(with appropriate warnings and so on) if a virus was written (very similar
  19. >to what rtm did), but instead it closed up the security holes that rtm
  20. >eventually used.
  21.   For one thing, we wouldn't be able to beleive it; we would STILL
  22. have to re-load our system. Our system files would fail their
  23. checksums and we would have no way of knowing what had been changed.
  24. After all, a program which fixed hole "x" could have left its own
  25. surprises in hole "y" for all we know.
  26.  
  27. >Those holes are the perfect example - after all, they *HAD* been fixed
  28. >as I understand it, but many people did not update their software to
  29. >fix them.  See what happens when you leave it up to the admins?
  30.      Well, that's the responsibility of the people who own and operate
  31. the systems. If your admin doesn't do his or her job, you need to find
  32. a better sysadm. It is tyrannical to force changes and improvements on
  33. those who do not want them. Let them live with the consequences of
  34. their own free choice of action. 
  35.     Perhaps 10 or 15 years ago there was an excuse for a system
  36. administrator to be ignorant of security issues. Nowadays, a system
  37. administrator who is ignorant of security is as out of place as a
  38. doctor who does not wash her hands before examining a patient. 
  39.    If a company pays for ignorance with failure....well, nobody dies.
  40. The information is available to anyone who wants to learn. Not just in
  41. obscure places; you can't pick up any conputer magazine or trade rag
  42. without seeing ads for security screaming out at you. Anyone who
  43. ignores all this is going to fail at something, be it security or
  44. development or some other part of their business.
  45.   Those of us who DO try to keep up will have our jobs made harder by 
  46. these viruses. If our security DOES work, on the other hand, we will
  47. notify the site which is the source of an attempted intrusion, so
  48. maybe they will get stopped up the line.
  49.   I'm worried about another thing too. If you can have a virus come in
  50. to "protect" me from bad viruses, what's to stop a virus from coming
  51. in and doing other things....opening the door to competitors, reading
  52. our files for signs of political or criminal activity, or any other
  53. sort of monitoring?
  54.   Nope, I want my system to run what we put on it and only what we put
  55. on it. 
  56.  
  57.  
  58.    
  59. --
  60. System Administrator                  Internet: betsys@cs.umb.edu
  61. MACS Dept, UMass/Boston               Phone   : 617-287-6448
  62. 100 Morrissey Blvd                    Staccato signals
  63. Boston, MA 02125-3393                      of constant information....
  64.