Pete Finnigan's Oracle Security Weblog
This is the weblog for Pete Finnigan. Pete works in the area of Oracle security and he specialises in auditing Oracle databases for security issues. This weblog is aimed squarely at those interested in the security of their Oracle databases.
I saw Lewis Cunninghams review of the book in a post titled 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.
The paper is available with one slide per page and also with six slides per page. Both are pdf files. The papers are available as usual from my Oracle security white papers page
I have also agreed to speak at the OUG event in Edinburgh at the end April so that should be fun as I have not been into Edinburgh for a long time, i have skirted around a few times in the car but not stopped. I have also agreed to speak at a security conference in Oslo in April so will update the speaking events section shortly.
I have also been working on our Oracle security service offerings, products, consulting and training sections of this website. These should go live soon so more about those here when i post them live.
The credits this time include some new names, this is good as it means that new people are investigating Oracle security. Thats good for us all. My name is there this time as well..:-), not new but its been a while since the last time.
There are 6 Application server fixes and one for collaboration suite and 7 for E-Business Suite and 4 PeopleSoft fixes.
I also think its interesting that there is a hint of Oracle working well with the researchers. The advisory credits Esteban for his help in ensuring that the fix is of the highest quality. This is positive!
The patch is also significant for its inclusion of the first 11g database security fix included in a CPU. Also as Amichai said "included a fix for a vulnerability whose function had no effect, as strange as it sounds" in a news post Oracle patch cycle includes first 11g database fix which is interesting if you know why!
Today Sentrigo have released a short press statement titled Survey of Oracle Database Professionals Reveals Most Do Not Apply Security Patches that discusses their findings over the last few months of taking a poll at various Oracle conferences and user groups. The results are shocking:
"This survey scares the heck out of me," said Mike Rothman, president and principal analyst, Security Incite. "The database is where most of an organization's critical and regulated data resides and if it's not patched in a timely fashion, organizations are asking for trouble."
But from my perspective not shocking as I talk to lots of my own customers (usually the discussion comes around to patching and CPU's) and also lots of Oracle's customers at various conferences and user groups that i attend. The recent round table at the UKOUG spent most of the time discussing the same subject and the feeling there was the same, that only a very small percentage of people install a CPU within the quarter (perhaps 1 - 5%), a slightly larger percentage do apply CPU's but usually not within the quarter. The worst figure is that around 80% never apply a CPU at all, although in my experience I come across a strange phenomina in this area that i find databases where a CPU has been applied but its perhaps 2 years old. This indicates to me that there was some effort in this area but then the company "gave up".
Sentrigo found that 10% of respondents had applied the latest CPU. There is some lag here though in that this could span two quarters so the figure may be worse. Then they found that 67.5 respondents had never applied a CPU.
There are companies out there who buck the trend (you know who you are!) and do apply CPU's consistently and to large numbers of databases successfuly and within around one quarter. It is possible and it can be done reliably.
I am starting to get the impression from talking to a lot of people that the issue has become psycological, a lot of companies beleive its difficult, that it will fail and that everything in the organisation needs to be regerssion tested. Remember that Oracle do re-release patches after a lot of feedback from customer applications and they do fix bugs found.
Patching should be easier (physically and on the mind!), afterall most people let Windows download and update automatically (Please don't take that as an indication that I think Oracle databases can be patched authomatically like Windows - I don't!) but the process can become easier.
As Slavik said, tools like Sentrigo's Hedgehog can provide an additional layer of security until you patch or for un-supported databases.
I saw today on the OakTable list a post Niall about a news item about Jeremy Clarkson of Top Gear fame. This article is titled "Clarkson stung after bank prank" and it talks about the fact that Clarkson posted his bank details in his newspaper column to make a point that the loss of the HMRC data to two CD's was a fuss about nothing. If you know anything about data security and identity theft you would be shaking your head if you read his column and sure enough someone created a direct debit and took 500 quid from his account and gave it to the charity diabetes UK. Don't mess with data, especially data that relates to your personal details; there will always be someone who can abuse it.