[8859] in bugtraq
Oracle8 TNSLSNR DoS
daemon@ATHENA.MIT.EDU (Jason Ackley)
Mon Dec 28 20:17:14 1998
Date: Mon, 28 Dec 1998 16:21:20 -0800
Reply-To: Jason Ackley <jason@ACKLEY.NET>
From: Jason Ackley <jason@ACKLEY.NET>
To: BUGTRAQ@NETSPACE.ORG
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
support@oracle.com
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 jason@ackley.net
