Re: Why are people so afraid of underscore parameters ?

In article <b3cb12d6.0208260630.9420a19_at_posting.google.com>, yong321_at_yahoo.com says...
>
>Thomas Kyte <tkyte_at_oracle.com> wrote in message
>news:<akc14j06hg_at_drn.newsguy.com>...
>>In article <b3cb12d6.0208251521.18cbe86a_at_posting.google.com>, yong321_at_yahoo.com
>> says...
>> >
>> >Thomas Kyte <tkyte_at_oracle.com> wrote in message
>> >news:<ak60ht02k5d_at_drn.newsguy.com>...
>>>>(in fact, I can show you a truly big problem with _trace_files_public,
>>security
>>>> and another undocumented but seemingly innocent event that can be set at the
>>>>session level -- just need _trace_files_public to be set and ALTER SESSION
>>privs
>> >> and I can get some pretty neat information)
>> >
>> >Hi, Tom,
>> >
>> >Out of curiosity, what event is that, suppose the user has alter
>> >session privilege?
>>
>> curiosity kills cats. I like cats.
>
>Killing a cat this way may not be that easy. I find that in Oracle 7
>but not beyond, you can use alter session to set blockdump event:
>
>alter session set events = 'immediate trace name blockdump level
>[level]'
>
>where [level] is the return value of the function
>dbms_utility.make_data_block_address ("documented" in Rama Velpuri's
>book). So people knowing how to interpret block dumps knows the values
>in the table even though he can't select on the table from inside the
>database.
>

again -- another reason why PERHAPS _trace_files_public isn't so *benign* after all -- thanks for supporting my argument.

Yet another security related issue if the DBA uses this undocumented init.ora parameter!

>But the difficulty with this security breach is that there's no
>select_catalog_role in Oracle7, and the file number and block number
>needed for dbms_utility.make_data_block_address is only available in
>dba_extents, not user_extents. So the user has to be granted select on
>dba_extents by SYS.

or they can just probe the database seeing what they can see. still a problem

>
>BTW, if the user can read block dumps, he's close to being able to
>read the datafile directly anyway. So the datafile permission has to
>be such that others (world) can't read to stop these "hackers". Not
>all databases have their datafile permission set that way.
>

well, I'd be for totally preventing access to the server itself but...

>I agree, there're more much easier exploits. Granting CONNECT role
>instead of CREATE SESSION is a bad one. You didn't seem to remind
>people about this in your book! But I haven't finished reading your
>book yet.

I didn't -- I had to limit the scope and I limited it to mainly development issues. Going down the "how to secure your system" route is another entire book!

>
>Yong Huang

--
Thomas Kyte (tkyte@oracle.com)             http://asktom.oracle.com/ 
Expert one on one Oracle, programming techniques and solutions for Oracle.
http://www.amazon.com/exec/obidos/ASIN/1861004826/  
Opinions are mine and do not necessarily reflect those of Oracle Corp