Oracle8 TNSLSNR DoS

From: Jason Ackley (jasonat_private)
Date: Mon Dec 28 1998 - 16:21:20 PST

  • Next message: Adam Maloney: "Fw: "NERP" DoS attack possible in Oracle"

    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
                                supportat_private
    
    
    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       jasonat_private
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:26:33 PDT