home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / security / misc / 2586 < prev    next >
Encoding:
Text File  |  1993-01-23  |  2.1 KB  |  48 lines
  1. Newsgroups: comp.security.misc
  2. Path: sparky!uunet!munnari.oz.au!cs.mu.OZ.AU!montebello.ecom.unimelb.EDU.AU!carl
  3. From: carl@montebello.ecom.unimelb.EDU.AU (Carl Brewer)
  4. Subject: Re: Unix Viruses. Are there any??
  5. Message-ID: <9302314.5488@mulga.cs.mu.OZ.AU>
  6. Sender: news@cs.mu.OZ.AU
  7. Organization: Dept. Engineering Computer Resources, Melbourne Uni.
  8. References: <senetza.727648754@honte> <1jootkINNhrv@matt.ksu.ksu.edu> <1jotp8INNiu@matt.ksu.ksu.edu>
  9. Date: Sat, 23 Jan 1993 03:50:00 GMT
  10. Lines: 36
  11.  
  12. In article <1jotp8INNiu@matt.ksu.ksu.edu> probreak@matt.ksu.ksu.edu (James Michael Chacon) writes:
  13. >senetza@sigma.uleth.ca (Len Senetza) writes:
  14. >
  15. >>so, get the source for something like ls (it's on ftp.uu.net).  then
  16. >>modify it so that it attaches a binary file which does x (x can be
  17. >>innocuous [print a smilie on the console] or destructive [halt]) to a
  18. >>system command (mkdir) which is installed suid.  then, go talk to the
  19. >>sysadmin and tell them that there is something wrong with your
  20. >>directory.  when they cd to it and do an 'ls' (your version), bango --
  21. >>virus.  this 'x' thing that the binary file does can also include
  22. >>copying itself to other programs.
  23.  
  24. 1: this is a trojan horse, not a virus.
  25.  
  26. >
  27. >>so, if root executes your ls, then x is attached to some program in the
  28. >>system.  have your x only do it to programs which are suid.  then it's
  29. >>all over the place; memory protection and file access controls fail
  30. >>here.
  31. >
  32. >>this assumes that root has . in its path, and how many root accounts
  33. >>out there do?
  34. >
  35. >No, this assumes root has . at the FRONT of his/her path. This of course is
  36. >extremely stupid and I believe covered in the FAQ.
  37. >
  38. >A scenerio like this assumes that the sysadmin is a pretty trusting person
  39. >and probably already has large security holes in the system.
  40.  
  41. a scenario like this assumes that the sysadmin should not be a sysadmin.
  42.  
  43. -- 
  44.  Annal  Natrach, Usthvah Spethed,         carl@ecr.mu.oz.au (IRC: Bleve)
  45.  Dochoel Dienve                           carl@munagin.ee.mu.oz.au
  46.                       carl@montebello.ecom.unimelb.EDU.AU
  47.  Merlin, where are you?  Call your dragon, to weave a mist...
  48.