home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / sysv386 / 14392 < prev    next >
Encoding:
Internet Message Format  |  1992-09-12  |  4.5 KB
  1. Path: sparky!uunet!munnari.oz.au!uniwa!DIALix!zeus!zeus!not-for-mail
  2. From: peter@zeus.DIALix.oz.au (Peter Wemm)
  3. Newsgroups: comp.unix.sysv386
  4. Subject: Re: perl 4.035 induces kernel panic in SVR4
  5. Date: 13 Sep 1992 10:57:00 +0800
  6. Organization: Karam Pty. Ltd., Perth, Western Australia.
  7. Lines: 90
  8. Message-ID: <18ualsINN2iv@zeus.dialix.oz.au>
  9. References: <1992Sep7.002515.15426@husc3.harvard.edu> <jrh.715877574@mustang> <1992Sep9.180635.27817@crd.ge.com> <1992Sep10.204557.15522@husc3.harvard.edu> <1992Sep11.145204.13475@crd.ge.com>
  10. NNTP-Posting-Host: zeus.dialix.oz.au
  11.  
  12. davidsen@ariel.crd.GE.COM (william E Davidsen) writes:
  13. >In article <1992Sep10.204557.15522@husc3.harvard.edu>, maziere1@husc8.harvard.edu (David Mazieres) writes:
  14. >|Thanks for all the help I've gotten.  In fact, my problem was simply that I
  15. >|was including libucb before libc.  I changed the library flags to -lc -lucb,
  16. >|and the new version tested fine. When I posted I figured I'd probably messed
  17. >|up the flags somehow-the really disturbing thing is that a non-root user can
  18. >|bring the whole system down.  I know the ucb library has tons of bugs in it,
  19. >|but should even the most bizarely warped and misused system calls panic the
  20. >|kernel?  (i.e. not should as in is this a good thing, but should as in have
  21. >|other people been able to crash their SVR4 kernels reproducibly)
  22.  
  23. >  I used to crash Dell regularly with a temp sensitive motherboard ;-)
  24. >Other than that I have never had a panic with Dell (or Intel, when I was
  25. >doing beta on that). It's been totally resistant to software causing
  26. >panics, one of the reasons I like it. I've never corrupted the
  27. >filesystems, either, no that I think of it.
  28.  
  29. There is a program that is periodically posted called "crashme". It is
  30. designed to do it's worst (or best) in an attempt to crash the kernel.
  31. There have been *SERIOUS* side effects every time time I have run it, 
  32. varying from instant panics, to trashing write protected files.
  33.  
  34. It sets up all signal handlers to point to some randomly generated trash
  35. and then attempts to run the "garbage" as code. This induces a recursivly
  36. called (and bombing) signal handler.   When the child finally died, the parent
  37. noted the fact in a log file, and launched another one (or something like
  38. that).
  39.  
  40. Some of the thinks I have seen.. (running as a "standard" user..)
  41.  
  42. * For a while, it would instantly panic the kernel. This changed after I
  43.    reconfigured the kernel some time later for a new driver.
  44. * Extreme performance degradation..
  45. * core dumps (there shouldn't be any - the resource limit for core files
  46.    was set to zero)
  47. * core dumps to WRITE-PROTECTED core files!!!
  48. * core dumps to WRITE-PROTECTED and ROOT-OWNED core files!!!
  49. * even core dumps in write-protected (and even root owned (like /etc))
  50.    directories!!!
  51. * corrupted executable!!! - even when the executable is write protected and
  52.    foreign owned...
  53.  
  54. This is what I mean....
  55.  
  56. Before:
  57.  
  58. dr-xr-xr-x   2 root     root         512 Mar 13 10:23 .
  59. ----------   1 root     root           0 Mar 13 10:22 core
  60. ---x--x--x   1 root     root       12560 Mar 13 10:23 crashme
  61.  
  62. After..
  63.  
  64. dr-xr-xr-x   2 root     root         512 Mar 13 10:26 .
  65. ----------   1 root     root         512 Mar 13 10:26 core
  66. ---x--x--x   1 root     root        4096 Mar 13 10:26 crashme
  67.  
  68. This is with "crashme" run as userid 103 (me).
  69. If I start with no core file, one i created, just the same..
  70. The executable is now corrupt... It resembles nothing like the original.
  71.  
  72. This was a fair while ago, but I still have the source that did this...
  73. I saved a directory listing before I deleted them, rebooted and fsck'ed.. :-)
  74.  
  75. This is on Dell 2.1 BTW (I Think.. It might have been 2.0.1 back then.
  76. I am not sure and I don't want to risk finding out...)
  77.  
  78. Imagine the consequences of typing this as a normal user...
  79.  
  80. cd /tmp (or somewhere on the root filesystem you can write to)
  81. ln /etc/passwd core
  82. crashme
  83.  
  84. Or how about
  85. cd /tmp
  86. ln /sbin/sh core
  87. crashme
  88.  
  89. This was on a UFS root filesystem, and at the time a "pristine" kernel.
  90. (No 387, and a 386-33, 16M ram, AHA-1542b)
  91.  
  92. -Peter
  93.  
  94. PS: The author of the program claimed that a suprising number systems he
  95. tried never made it past an hour of "stress testing".
  96. The known "bombable" cases listed in the source code include:
  97. Most Suns, DecStation 3100,5000, IBM RT, RS/6000, Iris4d 3.3.2, and Nixdorf.
  98. -- 
  99. Peter Wemm : peter@zeus.dialix.oz.au   If it's broke, fix it (The MS-DOS way)
  100. Work phone: +61-9-479-1855    If it aint broke, don't touch it (The Unix way)
  101. Fax: +61-9-479-1134   If we can't fix it, it ain't broke (Maintainer's Motto)
  102.