oracle8-tnslsnr-DoS.txt

`Oracle8 TNSLSNR DoS  
  
Jason Ackley ([email protected])  
Mon, 28 Dec 1998 16:21:20 -0800   
  
  
Greetings,  
  
I hope everyone had happy holidays with the IOS and Sun bugs, but now its  
time to get back to business.. Ohhh OK, one more DoS ! :)  
  
Hopefully this is new, I searched the archives for 'tns' and 'oracle', but  
only found things related to the Oracle web server..  
  
--  
  
While bored this holiday season, I wanted to learn a little more about SQL  
protocol level stuff..  
  
While attempting to see what the server sends as a banner (if any) I  
telnet'ed to port 1521 and tried things like:  
help  
version  
quit  
  
All to no avail. So I broke my telnet and resumed various other things and  
noticed that the tnslsnr had shot up to %99 CPU utilization, and was  
staying there.  
  
This was on  
  
LSNRCTL> version  
Connecting to (ADDRESS=(PROTOCOL=IPC)(KEY=ORCL))  
TNSLSNR for Linux: Version 8.0.5.0.0 - Production  
TNS for Linux: Version 8.0.5.0.0 - Production  
Unix Domain Socket IPC NT Protocol Adaptor for Linux: Version  
8.0.5.0.0 - Production  
Oracle Bequeath NT Protocol Adapter for Linux: Version 8.0.5.0.0 -  
Production  
TCP/IP NT Protocol Adapter for Linux: Version 8.0.5.0.0 -  
Production  
  
  
So, thinking that it was specific to the Linux version, I tested an NT  
box, and the same thing happened, using Task Mangler, the TNS listener  
shot to %99. This was Oracle 8.0.4.0.0-Production .  
  
Is it just me or is this bad?  
  
Does this happen to anyone else?  
  
If you dont want to type all three of the above lines, it just so happens  
that :  
  
kill  
oracle  
  
will do the same thing! :)  
  
I tried a Oracle7.x box (NT) and it seemed to be OK, it even cut me off  
after I typed the second line of 'version'..  
  
  
If you turn on tracing, you get something to the effect of:  
  
nsprecv: transport read error  
nsprecv: transport read error  
nsprecv: header checksum error  
nsprecv: bad packet header (plen=0x6b69)  
nsprecv: bad packet header (plen=0x6b69)  
[......]  
  
With 'bad packet header' repeating until you kill off your tnslsnr.  
  
  
The TNS listener still remains functional, although it is 'a tad' slow.  
:)  
  
Has Oracle been notified? - Well, if they are on BUGTRAQ, I guess they  
have been :) . I have CCed this to  
[email protected]  
  
  
Honestly, I am so amazed that this exists in such a program..I am almost  
not willing to believe it, except for the fact that it worked on both NT  
and Linux versions.. Can anyone try this on another oracle8 box, hopefully  
some different architectures?  
  
Scripts for the kids? - If you need a script for the above, I pity you.  
  
  
How to combat this? - If you haven't already, you should be refusing  
connections to your oracle hosts from untrusted machines and networks.  
Consult your oracle documentation or your DBA on how to do this.  
  
At your router, you could (and should) block access to the oracle ports,  
by default 1521 and 1526.  
  
A quick test of the Cisco CBAC feature (IOS Firewall set)on the sqlnet  
port did not appear to catch it. Do not assume that it will stop it, lock  
it down with an 'old fashioned' access-list, you should be able to sleep  
at night now assuming that no internal people try it :)  
  
Comments/other reports welcome.  
  
cheers and happy new year to all BUGTRAQ readers,  
  
---  
Jason Ackley [email protected]  
  
-----------------------------------------------------------------------------  
  
Date: Thu, 31 Dec 1998 12:07:57 -0800  
From: Aleph One <[email protected]>  
To: [email protected]  
Subject: Oracle8 TNSLSNR DoS [SUMMARY]  
  
Here are the systems reported affected:  
  
Oracle 8.0.5 Production under Windows NT and HP-UX.  
Oracle 8.0.4 Production under Solaris.  
Oracle 7.3.  
  
--  
Aleph One / [email protected]  
http://underground.org/  
KeyID 1024/948FD6B5  
Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01  
  
`