[Previous entry: "Howard Rogers writes about Virtual Private databases"] [Next entry: "Tools page has been updated again"]
Hiding literal strings in PL/SQL
October 7th, 2004 by Pete
Post to del.icio.us
Post to Furl
I just came across a posting on comp.databases.oracle.server about restricting access to the listener that was started a couple of weeks ago. The thread is here. This thread in itself is quite interesting anyway. But on a different subject in the last post by Yong Huang he mentions the following:
"A little off-topic. 10g also solved another minor security problem:
Literal characters in wrapped PL/SQL code are shown in plain text (see
http://groups.google.com/groups?selm=b3cb12d6.0205231329.6f0a4f5e%40posting.google.com).
Not any more."
A link to this thread is here and it talks about the issue of hiding a literal string in PL/SQL when the PL/SQL is wrapped. I also discussed this issue in the SANS Oracle security step-by-step guide book ISBN 0-9743727-4-9. Yongs original thread in 2002 gives a good example of the problem. I also talked about this issue in a paper written for a previous employer in Nov 2001 called exploiting and protecting Oracle. In that paper I discussed how some of the shipped packages provided by Oracle which are also wrapped also contain visible strings some of which are SQL strings. These could be altered by a hacker or employee to effect password changes or similar escalations of privileges. If the files are writable or can be accessed through one of many ways from within the database so that malicious code can be added. The hacker would then wait for the DBA to re-run the scripts which is quite feasible for instance after a patch application or upgrade and gain privileges.
The issue is fixed in 10g as Yong points out as 10g now completely encodes / encrypts the wrapped PL/SQL code so no strings or indeed any text is visible.
What about before 10g? – Is it possible to do anything to improve the situation? - The only options really are to remove all of the Oracle shipped PL/SQL files from the installation tree and add them back as needed or access them from a write once media such as CDROM when needed so that they cannot be edited. The same would apply to any application code. This would prevent alteration of the code but would not prevent reading of literal strings as these can still be read from the data dictionary. If the strings are critical, such as an encryption key then read them in from elsewhere or obfuscate them in some way.
10g makes the problem not a problem anymore though so if you use a lot of PL/SQL containing literal strings this improvement is one further reason to consider upgrading.
