.: 14x :: Generic Vuln - Many Vendors & Operating Systems :.

[Erik Tayler <nine () 14x net>]

Ok, I am going to try to make this as short and simple as possible. A simple "exploit/dos tool" was written quite a 
while ago named "octo" or "octopus". Here is a short description of octopus...

<snip>
*  This little program opens as many sockets with a remote
*  host as can be supported by both.  
</snap>
<snip>
 *  Often, a remote workstation can be brought
 *  to its knees by saturating its process table via multiple
 *  invocations of sendmail.
</snap>

If you really want to read the entire description, pick up a copy from ftp.technotronic.com/denial 

Not a whole lot of attention has been brought upon this, so maybe I could give another stab at it. I have tested octo 
on one of my old servers, which is a Cyrix 166+ - 46mb RAM, running xf86, sendmail, a pop3 server, ssh1/2, etc, with 
kernel 2.0.36. From a reasonably fast connection [DSL / T1], I used octo against my server...

# ./octo [myip] 6000

Attacking from a T1 with fair system specs, I was able to lock up the older machine's xf86, rendering the mouse 
useless, and obviously keyboard as well, making the only escape a reboot [reset button]. So I brought the server back 
up for another test.

# ./octo [myip] 25

I was on the console on the old server, continuously typing `uptime`, to check out what was happening. The load was 
skyrocketing [ I can't remember the exact figures ], and it took quite a long amount of time to get the load 
information back. Within moments, the whole system was locked, and a reboot was necessary again. So I brought it back  
up.

# ./octo [myip] 23

Different results this time. The older server slowed considerably yet again, but this time, it simple shut down my 
telnet service all together. So I restarted inetd.

# ./octo [myip] 22

Again, load increased dramatically, and system halted. Reboot again. Ok, instead of boring you, let me get to the 
point. Attacks such as this are extremely successful, harmful, and annoying. The system halting attack that was 
performed on ports 22, 25 & 6000 are now basically rendered harmless if the system being attacked runs anything newer 
than 2.0.36. However, using octo or similar tools against newer, faster servers still works.... By working, I mean that 
it has the ability to shut down services remotely. octo can halt many systems [ let me try to list all that I have 
tested it on... ].

RedHat Linux 5.2    - Halt + Service Closure
RedHat Linux 6.0    - Service Closure
RedHat Linux 6.1    - Service Closure
RedHat Linux 6.2    - Service Closure
Solaris 2.6             - Halt + Service Closure
SunOS < 5.7          - Halt + Service Closure
SunOS 5.7             - Service Closure
SuSE Linux 5.2      - Halt + Service Closure
SuSE Linux 5.3      - Halt + Service Closure
SuSE Linux 6.3      - Service Closure
SuSE Linux 6.4      - Service Closure
Slackware < 7        - Halt + Service Closure
Misc [ System V, Digital Unix, AIX, IRIX ] - Varied Results

Obviously there are ways to prevent this, such as setting limits on number of connections, tools such as portsentry, et 
cetera. But it seems that nobody has made any great strides to stop this sort of thing, and I believe it would be a 
good idea to do so. If anybody has any comments/ideas/feedback/flames, please e-mail me. Thank you.

Erik Tayler
14x Network Security
http://www.14x.net