{"vuid":"VU#936868","idnumber":"936868","name":"Oracle Database Server contains stack overflow in logging mechanism when supplied overly long library name","keywords":["Oracle","Database Server","EXTPROC","stack overflow","logging mechanism","long library name"],"overview":"There is a buffer overflow in several versions of Oracle Database. The impact of this vulnerability may include the execution of arbitrary code; the ability to read, modify, or delete information stored in underlying Oracle databases; and denial of service.","clean_desc":"A buffer overflow exists in Oracle9i Release 2, Oracle9i Release 1, and multiple versions of Oracle8i. For more detailed information on versions affected, please see Oracle Security Alert 57. The buffer overflow exists in a portion of code designed to log attempts to exploit a previously discovered vulnerability, described here: Oracle Security Alert #29 - \"Oracle PL/SQL EXTPROC in Oracle9i Database\"\nThe newly discovered buffer overflow is described in the following documents: Oracle Security Alert 57 - \"Buffer Overflows in EXTPROC of Oracle Database Server\"\nNGSSoftware Advisory NISR25072003 - \"Oracle Extproc Buffer Overflow\"\nIt is important to note that a discrepancy existed between these two documents. Specifically, the Oracle Alert asserted that only an authenticated user with privileges would be able to exploit this vulnerability. Quoting from Oracle Security Alert #29: Risk to exposure is low, as the CREATE LIBRARY or the CREATE ANY LIBRARY privilege is needed to exploit these vulnerabilities. On the other hand, the NGSSoftware Advisory asserts an unauthenticated remote attacker can exploit the vulnerability. Quoting from NGSSoftware Advisory #NISR25072003: As this does not require a user ID or password it must be stressed that this is a critical vulnerability. This discrepancy is being discussed in a public forum, too: Tina Bird's Post - <http://www.securityfocus.com/archive/1/330529>\nDavid Litchfield's Response - <http://www.securityfocus.com/archive/1/330566>\nOn 09/04/2003 Oracle Security Alert 57 was updated to read \"These potential vulnerabilities can be exploited in some cases without a username and password.\"","impact":"An intruder who exploits this vulnerability can remotely execute arbitrary code. On UNIX systems, this code runs as the 'oracle' user. From there, it is likely that an intruder could leverage that access to gain additional control over the system. If running on Windows systems, the intruder's code will run in the Local System security context. In either case, the data contained in the database is at risk.","resolution":"Apply a patch, as described in Oracle Security Alert 57. Note that Oracle has indicated the following in their security alert, \"Currently, due to architectural constraints, there are no plans to release a patch for versions 9.0.1.4, 8.1.7.4, 8.1.6.x, 8.1.5.x, 8.0.6.3, 8.0.5.x, 7.3.x, or other patchsets of the supported releases.\"","workarounds":"Workaround Until you can apply a patch, you may wish to follow the advice outlined in David Litchfield's Bugtraq post: Alternatively customers can disable external procedure functionality. To do this edit the listener.ora file, removing the entries for extproc, and also delete the extproc binary which can be found in $ORACLE_HOME/bin. It is important to understand your service requirements before deciding what changes are appropriate.","sysaffected":"","thanks":"This vulnerability was discovered by David Litchfield and Chris Anley of \nNGSSoftware Insight Security Research","author":"This document was written by Ian A Finlay.","public":["http://www.itnews.com.au/storycontent.cfm?ID=9&Art_ID=12499","http://otn.oracle.com/deploy/security/pdf/plsextproc_alert.pdf","http://www.databasejournal.com/news/article.php/2240701","http://otn.oracle.com/deploy/security/pdf/2003alert57.pdf"],"cveids":[""],"certadvisory":"","uscerttechnicalalert":null,"datecreated":"2003-07-25T19:32:55Z","publicdate":"2003-07-25T00:00:00Z","datefirstpublished":"2003-07-28T13:33:55Z","dateupdated":"2003-09-12T19:41:42Z","revision":34,"vrda_d1_directreport":"","vrda_d1_population":"","vrda_d1_impact":"","cam_widelyknown":"16","cam_exploitation":"0","cam_internetinfrastructure":"8","cam_population":"14","cam_impact":"18","cam_easeofexploitation":"9","cam_attackeraccessrequired":"16","cam_scorecurrent":"16.3296","cam_scorecurrentwidelyknown":"19.0512","cam_scorecurrentwidelyknownexploited":"32.6592","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":31.640625,"vulnote":null}