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 (gvs@agmar.ru) [http://www.agmar.ru/~gvs/]