Messages in this thread |  | | Date | Tue, 23 Jul 1996 23:54:58 -0400 (EDT) | From | David C Niemi <> | Subject | Re: Dumping /dev/zero to the console |
| |
I was a bit curious, so I did my own little test with this approach. First, I found just running a whole bunch of "cat /dev/zero &" processes is a great way to consume some CPU, but on my system it does not make the system unusable or even terribly slow. "cat /dev/zero > /dev/console" has the same effect as "cat /dev/zero" in whatever window I choose; perhaps some windows which interpret nulls would be more vulnerable. Something like while :; do echo done
...is at least as bad. And that does not require a device to take input from. Better yet, run 15 Netscapes!
Here's what the system looked like as I was running about 15 of these "cat /dev/zero" processes. I did not start them all at once, either, hence the disparities in priority and run time:
11:51pm up 3 days, 20:41, 8 users, load average: 16.65, 9.28, 4.41 72 processes: 68 sleeping, 4 running, 0 zombie, 0 stopped CPU states: 25.8% user, 74.4% system, 0.0% nice, 0.2% idle Mem: 14592K av, 14320K used, 272K free, 11112K shrd, 828K buff Swap: 66528K av, 11684K used, 54844K free 4004K cached
PID USER PRI NI SIZE RES SHRD STAT %CPU %MEM TIME COMMAND 250 root 19 0 6232 1836 620 R 17.7 12.5 9:16 X :0 1401 niemi 20 0 9660 28 20 R 16.4 0.1 82H netscape 5428 root 5 0 2352 804 592 S 8.0 5.5 0:17 xterm 12377 niemi 4 0 764 240 184 D 4.1 1.6 0:13 cat /dev/zero 12385 niemi 4 0 764 240 184 D 4.1 1.6 0:10 cat /dev/zero 12376 niemi 4 0 764 224 168 D 3.9 1.5 0:14 cat /dev/zero 12392 niemi 4 0 764 228 172 D 3.9 1.5 0:09 cat /dev/zero 12379 niemi 4 0 764 240 184 D 3.7 1.6 0:13 cat /dev/zero 12380 niemi 4 0 764 240 184 D 3.7 1.6 0:13 cat /dev/zero 12383 niemi 4 0 764 240 184 D 3.7 1.6 0:10 cat /dev/zero 12387 niemi 4 0 764 240 184 D 3.5 1.6 0:09 cat /dev/zero 12388 niemi 3 0 764 240 184 D 3.5 1.6 0:09 cat /dev/zero 12390 niemi 3 0 764 240 184 D 3.5 1.6 0:09 cat /dev/zero 12378 niemi 3 0 764 240 184 D 3.3 1.6 0:13 cat /dev/zero 12386 niemi 4 0 764 240 184 D 3.3 1.6 0:09 cat /dev/zero 12391 niemi 4 0 764 240 184 D 3.3 1.6 0:09 cat /dev/zero 12384 niemi 4 0 764 240 184 D 3.1 1.6 0:09 cat /dev/zero 12389 niemi 3 0 764 240 184 D 3.1 1.6 0:10 cat /dev/zero 12375 niemi 3 0 876 468 320 R 2.3 3.2 0:05 top 12413 niemi 2 0 780 296 224 S 1.7 2.0 0:00 du /opt/src 1 root 0 0 776 20 20 S 0.0 0.1 0:03 init
Certainly the difference is noticeable, but I have been on much slower systems which had no denial-of-service attacks running! The du /opt/src process is an attempt to do some intensive real work, and it went just fine. Admittedly, this is a pretty happy system, but cat /dev/zero is not a terribly fearsome attack.
DCN
--------------------------------------------------
Ted Ts'o wrote: From: lilo <TaRDiS@mail.utexas.edu> Date: Sun, 21 Jul 1996 10:44:25 -0500 (CDT)
/dev/zero can be used for a variety of things. It contains no sensitive information (only binary zeroes :) and hence conceptually its access should not be restricted.
There are a lot of other denial-of-service attacks that users can employ on Linux. If there's any interest in reducing the effectiveness of denial-of-service attacks (and improving Linux's handling of resource-exhaustion situations) that might be a better approach than simply denying access to this device.
It's also not hard thwart fix this sort of denial-of-service attack; just put in code to periodically check to see if need_resched is true, and call schedule() to yield control of the process. You should also check to see if a signal has been posted, and exit appropriately:
if (need_resched) schedule(); if (current->signal & ~current->blocked) return (bytes_written ? bytes_written : -ERESTARTSYS);
Any kernel system call which might be long-lived should definitely be doing something like this, just for robustness's sake.
- Ted
David Niemi@wauug.erols.com 703-810-5538 Reston, Virginia, USA ------ Money talks, but it is wrong half of the time. -----
|  |