Date: Mon, 24 Jul 2000 17:14:04 -0500
From: Erik Tayler <nine () 14X NET>
To: VULN-DEV () SECURITYFOCUS COM
Subject: .: 14x :: Generic Vuln - Many Vendors & Operating Systems :.
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
Intro
