- 11g (12)
- Allgemein (29)
- David Litchfield (7)
- Exploit (23)
- Forensics (7)
- Oracle Security (105)
- passwords (8)
- Repscan (1)
- Security (22)
- Sentrigo (5)
- software (9)
- source code audit (5)
- SQL Injection (24)
- Tools (24)
- Trainings (3)
- Tutorial (2)
- 18 Nov 2011: DOAG 2011 Presentation "Best of Oracle Security 2011"
- 15 Okt 2011: Oracle Critical Patch Update Pre-Release Announcement - October 2011
- 17 Sep 2011: Disable Auditing and running OS commands using oradebug
- 13 Apr 2011: Blackhat Training "HACKING AND SECURING ORACLE (2 days) "
- 2 Apr 2011: Oracle Database 11.2 Express Edition Beta comes with weak default password
- 23 Mrz 2011: McAfee acquires Sentrigo
- 12 Okt 2010: TDE decrypt utilities and TDE/Password flash demo
- 22 Sep 2010: Marcell published "Writing your own password cracker" presentation
- 21 Sep 2010: Laszlo's presentation "Oracle Post Exploitation Techniques" and Marcel's Sybase ASE Password Cracker
- 10 Sep 2010: Update of "Project Lockdown" released
Oracle Security
SQL Injection
- November 2011
- Oktober 2011
- September 2011
- April 2011
- März 2011
- Oktober 2010
- September 2010
- August 2010
- April 2010
- März 2010
- Februar 2010
- Januar 2010
- Dezember 2009
- November 2009
- Oktober 2009
- September 2009
- August 2009
- Juli 2009
- Mai 2009
- April 2009
- März 2009
- Februar 2009
- Januar 2009
- Dezember 2008
- November 2008
- Oktober 2008
- August 2008
- Juli 2008
- Mai 2008
- April 2008
- März 2008
- Februar 2008
- Januar 2008
- Dezember 2007
- November 2007
- Oktober 2007
- September 2007
- August 2007
- Juli 2007
- Juni 2007
- Mai 2007
Best (insecure) Practice PL/SQL on OTN
You already know that I like to analyze other people’s code. On OTN I found a nice article (most popluar developer article) “Best Practice PL/SQL from Steven Feuerstein” (http://www.oracle.com/technology/pub/columns/plsql/index.html).
Steven Feuerstein is a well-known expert on the Oracle PL/SQL language. His disclaimer says that “Do not take the advice and recommendations herein at face value. You should always build yourself a test case and run it on your database, for your schema, on your computer.” That’s OK but even (or especially) sample code should be secure. Disclaimers are a simple but not a good solution.
Especially if the code is posted as “Best Practice”.
The best practice contains some PL/SQL sample code for download, e.g. str2list.
“The str2list package accepts your string, delimiter, and the name of your package-based collection. It deposits the parsed items in your string directly into your collection. The collection can either be declared in the package specification (publicly accessible) or you can define it in the package body and then provide procedures to add to and delete from the collection. These will be called by str2list to populate the collection properly. It’s a useful utility as well as a great example of dynamic PL/SQL block execution.”
As always the same problem: no input-validation in some of the procedures (e.g. showlist or parse). This could allow an attacker to run custom PL/SQL code. PL/SQL injection is more severe than SQL Injection. I know that writing secure code takes time but I think it’s worth to do this, especially for sample code which is often used by many people. Just adding a disclaimer is in my opinion not the right way to deal with vulnerabilities.
A quick analysis of the code str2list.pkg (Source is from March 2005) shows the following vulnerable code:
—————— str2list.pkg ————————————————————
PROCEDURE showlist (
pkg IN VARCHAR2,
firstrowproc IN VARCHAR2,
nextrowproc IN VARCHAR2,
getvalfunc IN VARCHAR2,
showproc IN VARCHAR2 := ‘pl’,
datatype IN VARCHAR2 := ‘VARCHAR2(32767)’
)
IS
dynblock VARCHAR2 (32767);
BEGIN
dynblock :=
‘DECLARE
indx PLS_INTEGER := ‘
|| pkg
|| ‘.’
|| firstrowproc
|| ‘;
v_startloc PLS_INTEGER := 1;
v_item ‘
|| datatype
|| ‘;
BEGIN
LOOP
EXIT WHEN indx IS NULL;’
|| showproc
|| ‘ (’
|| pkg
|| ‘.’
|| getvalfunc
|| ‘(indx));
indx := ‘
|| pkg
|| ‘.’
|| nextrowproc
|| ‘(indx);
END LOOP;
END;’;
EXECUTE IMMEDIATE dynblock;
EXCEPTION
WHEN OTHERS
THEN
disperr (dynblock);
END;—————— str2list.pkg ————————————————————
3 Antworten auf “Best (insecure) Practice PL/SQL on OTN”
Antwort schreiben
Sie müssen als angemeldet sein, um einen Kommentar schreiben zu können.
1 Aug 2007 bei 09:35
Just pointing on someone else code and say it’s not secure is also just the half side of the truth. It would be much better to show the secure version, so that we can learn how it should look like and how we should write our code.
Thanks
Patrick
1 Aug 2007 bei 10:10
Patrick
it’s true that the secure version would be much better.
But I have only limited resources and for a secure version it is necessary to understand the code completely which can take some time. It’s typical for a source code audit to find vulnerable code but not to provide fixes. The developers are responsible for fixing the problems.
In the case of the package str2list you should restrict the parameter showproc or pkg, e.g. allowing only some special values (e.g. if pkg not in (’MYPACK1′,’MYPACK2′,’ORDER’).
Alex
1 Sep 2007 bei 10:06
Alexander,
Thanks so much for raising this concern about the code example. It does, indeed, contain a SQL injection vulnerability. I believe that it would actually be quite difficult to “bullet proof” this piece of code, given the generality of its desired functionality. I also expect that if anyone actually used it, its usage would be buried so deep inside an application that the possibility of external, malicious inputs to the program would be minuscule.
Minuscule is not, however, good enough when a person is sufficiently (and rightly) concerned about the security of their system.
Rather than come up with a new implementation of this program which would be secure from SQL injection, I have decided to remove the code sample from the OTN page.
Congratulations for making the Oracle PL/SQL world just a tiny bit safer for everyone!
Steven Feuerstein