Re: Interesting Exploit in PL/SQL

And to use the exploit the script relies on re-using the cursor. In my normal code I never put out a cursor number, because in most cases it is useless for me once i am done with it. I close my cursors like a good boy.

Debug messages generally are with parameters, critical data points. if someone gives pointers, exploits are in order ...

And yes, before more people start telling me, no debug code should never be enabled in production. That is if you make distinction between "debug code" and "code instrumentation".

Oh yes ... Dick, I got many db triggers in production that use dbms_output ... alas only if developers would listen ...

Raj

On 11/28/06, Richard J. Goulet <rgoulet_at_kanbay.com> wrote:
> 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
>
>
>

-- 
----------------------------------------------
Got RAC?
--
http://www.freelists.org/webpage/oracle-l