RE: Interesting Exploit in PL/SQL

 Tim,

        You have a point. When others then null leaves things in an undefined state that should be known about one way or the other. In reading the article I noted that he never recommended that, although just closing the cursor isn't a good thing either. If an error occurs in some code it should "phone home" with what happen to get it fixed. Also DBMS_OUTPUT should be banned from any production code. The package only works in certain interfaces, such as SQL*Plus, but will cause PL/SQL code to bomb at the worse time for the oddest of error messages.  

Dick Goulet, Senior Oracle DBA
45 Bartlett St Marlborough, Ma 01752, USA Tel.: 508.573.1978 |Fax: 508.229.2019 | Cell:508.742.5795 RGoulet_at_kanbay.com
: POWERING TRANSFORMATION -----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Tim Gorman Sent: Tuesday, November 28, 2006 9:36 AM To: Oracle-L Freelists
Cc: rjamya_at_gmail.com; mgogala_at_vmsinfo.com; jkstill_at_gmail.com Subject: Re: Interesting Exploit in PL/SQL

Please read it more carefully. "WHEN OTHERS THEN NULL" is *never* acceptable; he's saying to use WHEN OTHERS to close any cursors opened by DBMS_SQL before leaving the program unit.

In fact, WHEN OTHERS THEN NULL will still leave cursors open and exploitable, while neatly concealing the nature of any encountered exception, in addition to concealing the fact that any error occurred at all, to boot.

It is a piece of code that should be flagged as a compilation error by the PL/SQL compiler.

For coding stupidity, "WHEN OTHERS THEN NULL" is closely rivaled by "WHEN OTHERS THEN DBMS_OUTPUT.PUT_LINE('A serious error has occurred')", which brought a large consumer retail e-commerce website to its knees during Christmas season a few years ago. Talk about a million-dollar piece of code!

rjamya wrote:
> 1. stop comparing passwords
> 2. use exception handling " when others then null;" will defeat this
> exploit. So, this is one place where "when others then null;" is
> acceptable.
>
> There ... no more exploit.
> Let's get back to bashing 'latch free waits' or 'cache buffers
chains'.
>
> Raj
>
> On 11/27/06, Mladen Gogala <mgogala_at_vmsinfo.com> wrote:
>> Jared Still wrote:
>> > Not easily exploited, but still possible.
>> >
>> > http://www.databasesecurity.com/dbsec/cursor-snarfing.pdf
>> > <http://www.databasesecurity.com/dbsec/cursor-snarfing.pdf>
>

--
http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l