_\|/_ On Sun, 25 Jan 1998, Jason Downs wrote: >Here is a rather simple method of crashing most OpenBSD systems (and, I >assume, NetBSD or anything else running 4.4BSD vm without this problem fixed). Hmm.. on my P200MMX RAM 32 running FreeBSD 2.2.5-RELEASE with kernel options CHILD_MAX=128, OPEN_MAX=128, DFLDSIZ=(16*1024*1024) the execution of that script caused to "too many open files" at the user level and "can't open /usr/lib/libc.so" or some similar library at the system level (no logins, no execs and so on). Once the console received such message it hangs forever, and I couldn't switch to it anymore. But kernel did not panic and opened files still were available, as open network connections too (rlogins). Failed to stop this process, even when I pressed ^C at the console running that script, I used Ctrl-Alt-Del to reboot, and the filesystems were synchronized before reboot. After reboot I got the message `date` newsyslog[$PID]: log file turned over in /var/log/messages. Bad, bad condition. Any ideas to decrease user level privileges to keep system level resources still available under this attack? >Most, if not all, kernels have process limits high enough for a normal >user to run the kernel out of non-pageable map entries. The easiest way >that I have found to do this is with the enclosed script. > >If the per-user process/descriptor limits are high enough, running this script >will result in a kernel panic. [skip] SY, Seva Gluschenko, just stranger at the Road. --- IRC: erra * Origin: gone to the Internet (gvsat_private) [http://www.agmar.ru/~gvs/]
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:41:11 PDT