Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Funny sort of question re sys password

Re: Funny sort of question re sys password

From: Pete Finnigan <>
Date: Wed, 10 Mar 2004 23:09:25 +0000
Message-ID: <>

Hi Nuno,

Thanks for your comments.... some more comments in line In article <>, writes
>> Pete Finnigan <> wrote:
>> password and then having access as SYS - those methods are not social
>> engineering but hacking. I am trying to be vague as its not a good
>> idea
>> to show people in a public forum how to hack.
>Beg to disagree. If hacking techniques (including social engineering)
>are not made public, there is no way in the world we can expect people
>to learn how to "harden" their systems. I've learned a lot about how to
>secure my systems by frequenting hacker exploit sites. It's amazing what
>can be learned this way. Where I got l0phtcrack among so many others.

I think the issue is the difference between full disclosure and non full disclosure. This has been debated widely on forums like bugtraq and pentest  as to which is best. Its a matter for your own opinion as to whether you should reveal exploit code or just advise that there is a vulnerability and a patch or workaround to fix it or release the exploit as well. The bugtraq database has many exploits in it although a lot more advisories nowadays come out without exploits.

>The dblinks weakness has been around for a long time and is
>fixed I believe since 8.0. The command line uid/pwd weakness
>is common to any other product where one types passwords
>in the command line. A proper password check must always involve
>a challenge. Volunteering a password is the quick way to a cracked system.
>IMHO, it should be fixed by disallowing uid/pwd to be used in the command line.
>Ie, make SQLPuss and other commands not accept pwd in command line.
>The log files are a real problem. Proper protection on them is mandatory,
>but who bothers? I can count on one hand the number of sites
>I've been to in 15 years that had their log directories protected.
>The SGA dumping was news to me. A roundabout way, but effective.
>The SQL injection has been doing the rounds for a while and is not
>only Oracle's problem. The comms eavesdropping can be countered
>by using an encoded comm protocol. There are a few now that can be
>used with Oracle Net. But once again, I can count on one hand the
>number of sites where I have seen a custom Net setup including
>encryption. Too hard basket.
>April said it in one: increased security should be the default, not the option.
>Coming back to the initial concern, I still can't see how someone
>can claim to crack the Oracle security in 10 minutes. Other than by
>using external exploits. As far as I know, DES is still 10-minute

agreed, has to be an exploit, the 10 minutes intrigues me though unless they are waiting for a batch process to run so they can grab the password with ps. Anything else should take seconds.

If your DBA and sysadmin have cracked DES in less than 10 minutes then they should watch out the security agencies will want to employ them!!

kind regards


>> If
>> he is the sysadmin and he has an exploit and its not patched then
>> someone should be considering his loyalty to your company.
>Exactly. That is why I reckon exploits should be discussed openly.
>Otherwise the potential is there for someone to grab hold of one and do
>untold damage before others become aware it is possible.
>> SQL> alter user scott identified by tiger;
>> User altered.
>> and the SQL*Net trace shows:
>Yup. So if anyone has access to the trace, security is history.
>BTW, thanks for the feedback everyone. Much appreciated.

>Please see the official ORACLE-L FAQ:
>To unsubscribe send email to:
>put 'unsubscribe' in the subject line.
>Archives are at
>FAQ is at

Pete Finnigan
Web site: - Oracle security audit specialists
Book:Oracle security step-by-step Guide - see for details.

Please see the official ORACLE-L FAQ:
To unsubscribe send email to:
put 'unsubscribe' in the subject line.
Archives are at
FAQ is at
Received on Wed Mar 10 2004 - 17:14:51 CST

Original text of this message