Pete Finnigan's Oracle Security Weblog

I bought the pdf version of the book Practical Oracle Security by Josh Shaul and Aaron Ingram a few months back, in fact just after it came out and quickly read through it. In general the book flows well and the structure is good for a beginner but it has a number of bugs/inaccuracies in it.

I saw Lewis Cunninghams review of the book in a post titled http://blogs.ittoolbox.com/oracle/guide/archives/review-practical-oracle-security-21674 - (broken link) Review: Practical Oracle Security and thought I should probably make some notes about the issues I found in the book as well and make some comments here. Then today I noticed that Alex had posted a review about the same book back in November in a post titled review "Practical Oracle Security" and saw he had concerns about some of the accuracy as well. I also found some of the issues Alex did but I will just note some of my new concerns here where they are different to Alex's, this is not an exhaustive list:

My first general comment is that there is quite a bit of "filler" in the book, that's not a major issue, just for my taste i would have left it out and had a shorter more compact book like David's Oracle Hackers Handbook.

page 25 - Password_verify_function - "This setting points Oracle to a user defined function typically written in C." - what? - OK, its possible to create a verification function written in C but why would you do this? - i have never seen one and typically they are always written in PL/SQL not C.

Page 44 - seems to imply that sql auditing is achieved using 10046 trace??? - this confimed later on where the authors suggest an attacker would "flood" trace files with rubbsish using dbms_system.ksdwrt "if auditing is on" - This confirms that the authors probably don't know what the difference between trace and audit is. Who have you ever seen use 10046 as an audit trail? Also the analysis section is nonesense as tkprof would pull out the SQL anyway and reveal what had happended.

Page 44 - I am sorry but why do you need to find ELF files? - any file writable by the oracle process whether ELF or not (in fact anyone who can ammend an ELF file doesn't need help attacking Oracle) can be turned into a shell script, perl or whatever - what is that section about?

Page 65 - as an example fine but this bug goes back to Oracle 8, it's not really relevant at all in a new book on Oracle security, a new example would have been better.

Page 67 - the syntax is wrong, it should be PASSWORDS_listenername not PASSWORD_listenername - also recommending clear text passwords is mad in this day and age.

Page 76 - in valid node checking mixing hostnames and IP addresses will create unstable behaviour as both are not supported together.

Page 105 - The password algorithm is well documented now. They have got it completely wrong. this is suprising as sample code is available from mutliple sites and even Oracle says its a modified DES not 3DES in their documatation.

page 123 - not true, not all USER% and ALL% tables/views are granted to public

page 124 / 138 / 139 and on 141 - there is a fundamental issue in that the privileges discussion focuses on them being granted to PUBLIC, the system privilege section and the ANY privilege section are good examples. Why is the focus on PUBLIC. if an ANY privilkege is granted to any user it becomes dangerous?, the same in page 141 on single privileges such asalter system. This focus on PUBLIC is wrong.

In general the structure of the book is fine, the level of detail is good for someone who is new to Oracle security and securing an Oracle database. I think the biggest concerns for me as Alex said is that some advice makes a database less secure and also the whole section on roles, object privileges and system privileges ignores that these are an issue if granted to a user who should not have them and instead focusses on the issues with them being granted to PUBLIC. That is still an issue but as the book stands it leaves the reader thinking that the only issue is with PUBLIC. Some of the silly mistakes also detract from confidence in the rest of the book, such as blank passwords or the password algorithm being wrong. Lets hope that there is a reprint and some of the issues can be ironed out and fixed. I tried to find how to report these on syngress.com but the site is unavailable as I write this.