"Within 42 hours I was able to find 42 bugs with security potential (e.g., denial of service, SQL Injection, …)," RDS' Alexander Kornbrust said from Germany via an e-mail conversation. "I stopped after 42 bugs." He said he then reported the bugs to Oracle.

This paper offers excellent hints for placing real-world Oracle database details on MOSC:

• Customers should use, if possible, a freemail account in forum entries.
• Anonymous configuration files when posting on MOSC
• Remove passwords before posting content on MOSC
• If you are reporting a bug to Oracle think of the possibility that this bug could be security related and escalate it if necessary. Even, if this costs additional time and money it would make Oracle more secure in the long run.
• Oracle analysts should become more security aware and try to avoid providing insecure advices like removing listener passwords, submitting xhost+, …
• Oracle secalert should check MOSC on a regular basis because very often, customers post security details to public forums (see Switch SYS via dbms_scheduler)

The original paper is titled "MOSC Hacking".  Later articles have been written about the issue of inadvertent disclosure of company database information.  Details are here. 

Publish and Perish

Publishing STATSPACK reports and AWR reports on the web can be extremely dangerous, especially for web-enabled Oracle databases, where the malicious hacker might see the exact configuration of the instance, details about the application PL/SQL and the actual Oracle SQL. To a hacker, being able to examine the SQL might help them use Oracle SQL injection hacking to break-in to a database.  For example, using semi-colons in SQL might open-up a SQL injection exposure in SQL Server.  In Oracle, security expert Pete Finnigan page on Detecting SQL Injection In Oracle:

"SQL Injection is a way to attack the data in a database through a firewall protecting it. It is a method by which the parameters of a Web-based application are modified in order to change the SQL statements that are passed to a database to return data. For example, by adding a single quote (‘) to the parameters, it is possible to cause a second query to be executed with the first. "

For example, this simple Google Search reveals proprietary details about several real-world Oracle databases including a listing of all parameters, the instance and server name, the IP address of the server and actual examples of the production SQL.

Be careful when asking for help

If your company has Oracle professionals who participate in web forums, make sure that they do not fall into a disclosure trap.  All Oracle professionals should be wary of anyone who insults them or claims that withholding a reproducible test case from your client is "dishonest":

"I fear many (excluding Mr. Burleson, or Mr. Ault) who would oppose Tom's 'Scientific' method prefer the dishonest methods described, above, as a cover just to pad their bank account and get out the door so they can get on to their next victim."

The false allegation of dishonesty above might tempt the author to disclose confidential client information, and anyone who shares information about their on-the-job experiences should be especially wary of anyone who demands that you "prove" your observations with a repeatable real-world test case.  Oracle managers should establish strict privacy policies that require all published information to be thoroughly obfuscated.

Obfuscation of client data is not dishonest, it is a contractual requirement by your clients. Recently, anonymous people have alleged that data obfuscation is dishonest and that our consultants are guilty of fabricating empirical evidence. If you are accused of being dishonest, immediately report it to your duty manager, and we will take the appropriate actions to protect your honor and reputation.

We are under no obligation whatsoever to provide reproducible evidence or test-cases to beginners and it is our readers trust in our judgment and real-world experience that counts. Resist the temptation to fall-in to the “prove it” trap.

A comprehensive corporate policy should clearly spell-out the risks and punishments for publishing inappropriate details about your database.  Even in Oracle-owned forums, answering "prove it" questions by providing detailed evidence with STATSPACK and AWR reports on the web is extremely dangerous.