{"vuid":"VU#105259","idnumber":"105259","name":"Oracle Database Server vulnerable to DoS via repeated requests to Oracle listener without connecting to redirected port","keywords":["Oracle Database Server","Windows NT","DoS","denial of service","redirect request","redirected port","Oracle listener","consume all memory"],"overview":"Oracle Database Server may consume all available memory and crash if clients do not connect completely in the expected manner.","clean_desc":"When a connection request is made to Oracle for Windows NT, Oracle Database Server creates a new thread listening on a new port and redirects the connection to the new port. This new thread remains in memory listening until the client connects to its port or the Oracle Database Server is restarted.","impact":"By making many connection requests to Oracle without connecting to the new threads created to handle the connections, an attacker can force the server to consume all memory with listening threads. Once all server memory is consumed, the next console login attempt will crash the server.","resolution":"The CERT/CC is currently unaware of a practical solution to this problem.","workarounds":"Enable tcp.validnode_checking and set tcp.invited_nodes and tcp.excluded_nodes to limit Oracle access to trusted hosts. Set the following parameters in the Oracle Net8 configuration file PROTOCOL.ORA: tcp.validnode_checking = YES\ntcp.invited_nodes = {list of IP addresses}\ntcp.excluded_nodes = {list of IP addresses}","sysaffected":"","thanks":"Thanks to Internet Security Systems (ISS) for their advisory on this issue.","author":"This document was written by Shawn Van Ittersum.","public":["http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2001-0513","http://xforce.iss.net/alerts/advise81.php","http://xforce.iss.net/static/6717.php"],"cveids":["CVE-2001-0513"],"certadvisory":"","uscerttechnicalalert":null,"datecreated":"2001-06-20T16:14:38Z","publicdate":"2001-06-19T00:00:00Z","datefirstpublished":"2001-12-08T22:40:53Z","dateupdated":"2004-01-14T20:43:29Z","revision":18,"vrda_d1_directreport":"","vrda_d1_population":"","vrda_d1_impact":"","cam_widelyknown":"15","cam_exploitation":"0","cam_internetinfrastructure":"9","cam_population":"10","cam_impact":"3","cam_easeofexploitation":"14","cam_attackeraccessrequired":"16","cam_scorecurrent":"3.024","cam_scorecurrentwidelyknown":"3.654","cam_scorecurrentwidelyknownexploited":"6.174","ipprotocol":"","cvss_accessvector":"","cvss_accesscomplexity":"","cvss_authentication":null,"cvss_confidentialityimpact":"","cvss_integrityimpact":"","cvss_availabilityimpact":"","cvss_exploitablity":null,"cvss_remediationlevel":"","cvss_reportconfidence":"","cvss_collateraldamagepotential":"","cvss_targetdistribution":"","cvss_securityrequirementscr":"","cvss_securityrequirementsir":"","cvss_securityrequirementsar":"","cvss_basescore":"","cvss_basevector":"","cvss_temporalscore":"","cvss_environmentalscore":"","cvss_environmentalvector":"","metric":3.024,"vulnote":null}