The infamous book "Unix Hater's Handbook"xi gives the following example of a simple DoS attack (using recursion): #!/bin/sh $0 & exec $0 The author continues: "once they (these attacks) are launched, the only way to regain control of your Unix system is by pulling the plug beacuse no one can run the ps command to obtain the process numbers of the offending processes... No one can even run the su command to become Superuser!... And best of all, any Unix user can launcg this attack." I thought that this type of problems were fixed in Linux (by limiting child processes etc) and I think that I tested this variant some years ago and the system refused to "go down". I therefore got an unpleasant surprise When one of my students run the following variant while true ; do sleep 5000 & echo "sleep" done and got the system on it's knees. I tested the "Hater" variant and it "worked" too. The error message given from the system when running the sleep variant was: Too many open files in system cannot redirect standard input from /dev/null: Too many open files in system ./testsleep: /bin/sleep: Too many open files in system The "classical" script gives similiar messages. The kernels tested are 2.2.19 and 2.4.10-25 and both give the same result. Something for the kernel people to consider???!!! Best regards Martin F
The infamous book "Unix Hater's Handbook"xi gives the following example of a simple DoS attack (using recursion):
#!/bin/sh $0 & exec $0
<snip>
Something for the kernel people to consider???!!!
Use ulimit to set sensible limits. If you don't, then don't be surprised when this happens. I rememeber Alan Cox saying something to this effect on this problem. It most certainly is not a kernel problem. Good luck, Jurriaan
Yup, On 19-Dec-01 Jurriaan Kalkman wrote: [...]
Something for the kernel people to consider???!!!
Use ulimit to set sensible limits. If you don't, then don't be surprised when this happens. I rememeber Alan Cox saying something to this effect on this problem. It most certainly is not a kernel problem.
Good luck, Jurriaan
You can also directly modify limits.h in the kernel include directory (usually /usr/src/linux/include/linux/limits.h if you want to build a dedicated server with local users. This way, you may save some time because you don't have to set and administer soft limits on a per-user basis. Boris Lorenz <bolo@lupa.de> ---
Not necessarily. I agree that it's dismal, but all good system administrators set appropriate ulimits for their users. See the ulimit manpage for your shell(s). Parameters to pay particular attention to are max open file descriptors, cpu seconds used, and processes available to the user. (This is after a fleeting test here, so I've obviously not caught everything.) --- Dan Chen crimsun@email.unc.edu GPG key: www.unc.edu/~crimsun/pubkey.gpg.asc On Wed, 19 Dec 2001 martin@as3-1-1.hn.g.bonet.se wrote: [...]
I thought that this type of problems were fixed in Linux (by limiting child processes etc) and I think that I tested this variant some years ago and the system refused to "go down". [...]
The kernels tested are 2.2.19 and 2.4.10-25 and both give the same result.
Something for the kernel people to consider???!!!
Best regards Martin F
On Wed, 19 Dec 2001, Daniel T. Chen wrote:
Not necessarily. I agree that it's dismal, but all good system administrators set appropriate ulimits for their users. See the ulimit manpage for your shell(s). Parameters to pay particular attention to are max open file descriptors, cpu seconds used, and processes available to the user. (This is after a fleeting test here, so I've obviously not caught everything.)
I am using the "default" values: open files 1024 pipe size (512 bytes) 8 max user processes 4095 memory, stack and cpu time are unlimited It's obvious that these values don't work. What are "appropriate ulimits" here? Best reegards MF
That depends on what you're comfortable with as an administrator. For my quick test I chose a max of 100 open fds, 5 cpu seconds, and 100 user processes (/bin/zsh). I was able to successfully `killall test` as well. You will need to estimate what your users might need and adjust them accordingly. --- Dan Chen crimsun@email.unc.edu GPG key: www.unc.edu/~crimsun/pubkey.gpg.asc On Wed, 19 Dec 2001 martin@as3-1-1.hn.g.bonet.se wrote:
I am using the "default" values: open files 1024 pipe size (512 bytes) 8 max user processes 4095 memory, stack and cpu time are unlimited
It's obvious that these values don't work. What are "appropriate ulimits" here?
Best reegards MF
On Wed, 19 Dec 2001 martin@as3-1-1.hn.g.bonet.se wrote:
while true ; do sleep 5000 & echo "sleep" done
and got the system on it's knees. I tested the "Hater" variant and it "worked" too.
The error message given from the system when running the sleep variant was:
Too many open files in system cannot redirect standard input from /dev/null: Too many open files in system ./testsleep: /bin/sleep: Too many open files in system
I tested that on SuSE 7.3, Kernel 2.4.15aa1 while logged in as normal user on /dev/tty. I did not get the system to it's knees BUT: During the 'while' run i was also logged in as root on the second console. The following happened: root[root]# top Segmentation fault root[root]# man top Segmentation fault root[root]# killall sleep root[root]# top [...] top runs [...] root[root]# man top [...] man top [...] Of course no coredumps are written (file with 0 bytes, ulimit -c > 0). Don't know how many binaries are affected by that but man (link to mandb) runs setuid root. Also to mention: The segfaults don't occur when man or top are executed as normal user. Bash then complaints about too many open files and goes back to the normal prompt. Best regards, --Andreas
I tested that on SuSE 7.3, Kernel 2.4.15aa1 while logged in as normal user on /dev/tty. I did not get the system to it's knees BUT:
During the 'while' run i was also logged in as root on the second console. The following happened:
root[root]# top Segmentation fault root[root]# man top Segmentation fault root[root]# killall sleep root[root]# top [...] top runs [...] root[root]# man top [...] man top [...]
Of course no coredumps are written (file with 0 bytes, ulimit -c > 0). Don't know how many binaries are affected by that but man (link to mandb) runs setuid root.
Also to mention: The segfaults don't occur when man or top are executed as normal user. Bash then complaints about too many open files and goes back to the normal prompt.
Best regards, --Andreas
Can you please try again with the kernel from ftp://ftp.suse.com/pub/people/mantel/next/RPM/ ? Roman. -- - - | Roman Drahtmüller <draht@suse.de> // "You don't need eyes to see, | SuSE GmbH - Security Phone: // you need vision!" | Nürnberg, Germany +49-911-740530 // Maxi Jazz, Faithless | - -
On Wed, 19 Dec 2001, Roman Drahtmueller wrote:
I tested that on SuSE 7.3, Kernel 2.4.15aa1 while logged in as normal user on /dev/tty. I did not get the system to it's knees BUT:
Can you please try again with the kernel from ftp://ftp.suse.com/pub/people/mantel/next/RPM/ ?
Roman. --
I tested that again with vanilla 2.4.16 patched against suse-2.4.16-7.bz2 from Hubert Mantel (i did not want to download the ~13 MB rpm file - i only have a slow ISDN dialup connection ;-( ). The result is the same as with 2.4.15aa1. top and man both segfault. I searched a little bit in the source codes and found out that both programs seem to have bugs that causes them to operate with zero pointers. Best regards, --Andreas
I tested that again with vanilla 2.4.16 patched against suse-2.4.16-7.bz2 from Hubert Mantel (i did not want to download the ~13 MB rpm file - i only have a slow ISDN dialup connection ;-( ). The result is the same as with 2.4.15aa1. top and man both segfault.
I searched a little bit in the source codes and found out that both programs seem to have bugs that causes them to operate with zero pointers.
Thanks for what you found out and sent me in the private mail. We'll handle it.
Best regards, --Andreas
Thanks, Roman. -- - - | Roman Drahtmüller <draht@suse.de> // "You don't need eyes to see, | SuSE GmbH - Security Phone: // you need vision!" | Nürnberg, Germany +49-911-740530 // Maxi Jazz, Faithless | - -
martin@as3-1-1.hn.g.bonet.se a écrit :
The infamous book "Unix Hater's Handbook"xi gives the following example of a simple DoS attack (using recursion):
#!/bin/sh $0 & exec $0
Why infamous ? People have a right to like or dislike, even hate whatever they want to. This book is a MUST for anybody working with Unix/Linux. Unix/Linux certainly can be improved and this book is helpfull to find out about Unix/Linux' weakness. -- ~adj~ Ces mystères nous dépassent Feignons d'en être l'organisateur...
This is so retarded. Load linux onto a 386/sx15 and run a compile. Shoot, you just dos'ed the system. This is why you need to place appropriate limits on users, preferably using PAM, ulimit is bash specific, if the user chsh's, well whoops. http://www.seifried.org/lasg/users/ Between this and the MS bashing thread I think it's time for moderation, which of course introduces a large latency issue which kind of sucks. Perhaps the addition of a new moderated list to supplement this one is in order. Kurt Seifried, kurt@seifried.org A15B BEE5 B391 B9AD B0EF AEB0 AD63 0B4E AD56 E574 http://www.seifried.org/security/
participants (8)
-
Alain DIDIERJEAN -
Andreas Amann -
Boris Lorenz -
Daniel T. Chen -
Jurriaan Kalkman -
Kurt Seifried -
martin＠as3-1-1.hn.g.bonet.se -
Roman Drahtmueller