Date: Mon, 28 Dec 1998 16:21:20 -0800 From: Jason Ackley <jason@ACKLEY.NET> Subject: Oracle8 TNSLSNR DoS 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