Pete Finnigan's Oracle Security Weblog

I have just updated my Oracle Security site home page which includes speaking dates down the left hand side towards the bottom of the page. I am going to be speaking in Iceland in September - doing my 2 hour Oracle Security master class and again giving the same 2 hour master class at the White-Hats event at the institute of directors in London at the end of September. I am also doing two sessions at the UKOUG conference in Birmingham in December; one is the Oracle security round table and the second is my Oracle Security Basics talk that I did back in February. I will enhance it slightly and do some basic demos. I should say that this is not a basic talk, its back to basics and is aimed at getting the fundamentals down on Oracle security. The talk went down very well in paddington, London earlier in the year. Details of my speaking schedule are on my Oracle Security home page.

I have also updated my training class public schedule. My two day class on how to perform an Oracle database security audit training course has gone down very well on the many occasions it has been held this year both private and public. The class details from cradle to grave how to plan, execute and write up an Oracle database security audit. The details of each public event are shown at the bottom of the page. I am holding 4 classes with the Oracle University in Holland, Sweden, Germany and Norway in November and December. The dates and registration pages are available on my Oracle database security audit training page. We are also holding public training days for the same class in London and Edinburgh on a number of days. There are still a small number of places available for the August event, please contact me for details of registration if you would like to attend.

Oracle released their first security alert in three years outside of the Oracle Critical Patch Update (CPU) process on the 28th July. An unknown German (according to Alex's blog he is German) hacker calling himself Kingcope has released a 0-day exploit for Apache for the BEA Weblogic plug-in for Apache. The BEA Weblogic site has an advisory titled "Security Advisories and Notifications" which describes the issue. The exploit has a CVSS rating of 10.0 which makes it a high risk issue. It is a Denial of service attack and no authentication is required. The advisory from BEA (Now Oracle) advises a workaround of adding the line:

LimitRequestLine 4000

To the httpd.conf file and restarting Apache. If URL's have to be longer than 4000 bytes then mod_security can also be considered.

Eric Maurice has also released a note on his blog titled "Security Alert for CVE-2008-3257 Released" with more details. Oracle's own advisory is titled "Oracle Security Alert for CVE-2008-3257". There is also a news item over on E-Week Oracle Sounds Alert Over Unpatched WebLogic Server Flaw:

"Hackers have released exploit codes for an unpatched flaw affecting the Apache plug-in for Oracle's WebLogic Server. While Oracle prepares a patch for the vulnerability, it has provided information on workarounds to help ensure enterprise security.


Oracle officials are issuing a red alert regarding a flaw affecting the Apache plug-in for Oracle WebLogic after exploit codes for the vulnerability were posted in public forums."

There was a post on my Oracle Security forum a couple of weeks ago that i found very interesting and worthy of a note on this blog. A poster raised a good question "Oracle Security is GOOD enough?" :

"Hi All,

please share your point of view about Oracle security at this moment.

In my opinion, I see less Oracle Security vulnerabilites in the newer Oracle version and less persons researching about Oracle Security (because Oracle is good now).

Oracle security getting better by time so no need to care about Oracle Security anymore, it's right ?"

This is an interesting question. Marcel-Jan added this response:

"You have to ask yourself: why do security leaks occur in Oracle databases:
- Because of passwords (on privileged accounts) that lack complexity and which are never changed.
- Because an application with SQL injection leaks connects to the database with an over-privileged account.
- Because the DBA thought it kinda easier to grant every object privilege to PUBLIC.
- Because the database runs an old version that is never updated (nor CPUs are applied), because you should never change a running system.
- etc. etc.
- or: because Oracle has a vulnerability in the dbms_obscurity package that allows to shutdown the database in certain occasions on certain platforms.

I'm betting that most organisations suffer more from problems like the first four (many variations exist). So Oracle isn't per definition secure after applying the latest patch. A lot depends on work done by the DBA and developers.

Try Project Lockdown (http://www.oracle.com/technology/pub/articles/project_lockdown/index.html) for a better start towards Oracle security."

The poster replied with:

"Agree with you that most vulnerabilities listed existing in the Production Database.

We can clasify the Oracle vuls by two type:
1. Oracle Software vuls: weak PL/SQL packages ... (Update lastest patch can solved this; less vuls in Oracle 10.2.0.3 and 11g, and will be near zero in the next release, hope this )

2. Misusing of Oracle Database: weak password, configurations, coding. (GOOD DBA or Developer can solved this partly, not all)

But in my expierience, Customer who using Oracle product just pay attention in Oracle Security when they see more vulnerabilites in Oracle Software, seem they really not care much about Misusing of Oracle Database.

One thing that cause me thinking that Oracle is GOOD enough at this time and future is not see more public vulns or frequently posted news in David, Alex or Pete blog during several months."

Then I had my go with the following:

"Nice post and answer by Marcel-Jan; I think that there are two answers to this point vpv. The first is that the database software itself is getting better with later versions in regards to vulnerabilities etc. Thats fine and is commendable for Oracle.

The second issue for me is that the CPU application doesnt fix security. In my opinion the CPU/Security patch and therefore bugs actually in the software is a smaller part of the overall security of the database, maybe 20% - 30% and at the end of the day we can either patch or not. If someone finds a bug there are enough vendors now in the Oracle security space that many people will know how to exploit the issues so applying CPU's is important.

The other 70% of security and in my experience where most people / customers of Oracle fall down is around the configuration, data leakage, weak passwords, no network security at the Oracle level, excessive privileges.... and much much more. This is compounded by the fact that most people do default installs and install too much increasing the attack surface.

I dont know if there is one root cause but the issue for me is lack of understanding of database security or often lack of effort at all in this area, so most people have badly configured and managed databases.

So whilst you are right and I agree the software is getting better its also getting bigger and open by default and most do not do anything to close off the configuration so the state of most databases is not secure at all.

Its a complex subject and you certainly cannot ignore Oracle security based on better product/less vulns or lack of blog posts.

I think the upsurge in a large number of vendors in this space such as Sentrigo hedgehog shows that there is a major interest in securing data. regulatory issues such as PCI DSS 1.1, SoX, HIPPA and more also underscore this.

I give clues in my sparce blog posts as to why I dont make many, i.e. I am employed heavily in securing databases, I know Alex is the same and I suspect David as well. I think the lack of blog posts doesnt signify better security; it just means we are busy.. "

I think that this is a very interesting question and a good discussion. My views as you can see above is that the database software itself is getting better, people (customers of Oracle) are starting to embrace the need to secure data in the database itself and there is starting to be a recognition that the products are complex and that most of the issues lie in the realms of configuration not with bugs. Of course Oracle could help us a lot by getting to the point of a "secure out of the box" product rather than the open by default product that caters more towards use and developers rather than security mongers like me.

The poster had an interesing conclusion, the fact that the product is getting better and the fact that known Oracle security bloggers post less should be a reason to ignore Oracle security because based on this its getting better. I hope that people take heed of this post and also do not take the same view as the poster otherwise we would have a data security problem. The conclusion would be (from this point of view) that if no one does research or blogs about the subject the database would be secure? - this unfortunately falls under the "ignorance is bliss" category.

What do other people think?, is Oracle security getting better? or is it good enough?

I promoted the IOUG/Oracle security survey a few weeks back in a post titled "An Oracle Security Survey by The IOUG and Oracle" and today i received an email from John at the IOUG to let me know that the survey ends on July 31st.

I would ask everyone who has any level of interest in securing their Oracle database to take a few minutes to fill in the survey. It is important that everyone has their say. This is a very good way to get Oracle to make any changes in regards to areas such as CPU's or to tell Oracle that you are happy with the changes made over the last few years in regards to security. It is important that we get a good mix of views, i.e. don't assume that this is a survey to make complaints, its not, its a survery to capture views of as many Oracle customers as possible about securing the database.

The survey closes on 31st July so please take a few minutes to fill it in. The survery can be found at http://survey.ioug.org/ and then choose the OSSA Security Survey II survey. The site is not onerous, you simply choose a username and password and then proceed.

I saw today that Kurt Van Meerbeeck who is famous for writing jDUL that became DUDE has started a blog. I have known Kurt for many years on email but only in the last couple of years have we met in person at the UKOUG conference. Kurt's blog has only one post so far "A new ORA600 website - a new blog, DUDE !" but is certainly worth keeping an eye on.

Why should we be interested from a security perspective? - well as I said I have known Kurt for many years (I just checked, our first email exchange was in 2001 when we talked about jDUL) on email and I am always fascinated by internals, undocumented details and more. Oracle security is not about simply looking at security features in the database. Every feature, especially if its enabled in the database (note: enabled in security terms does not mean used!) has some security risk level. For instance, the useful package DBMS_FILE_TRANSFER sounds useful if you are writing an Oracle based application that needs to allow files to be transfered. From a security perspective it's dangerous as it would allow files to be manipulated from within the database. The procedures GET_FILE and PUT_FILE sound useful to a hacker.

So in general all features have some risk in some circumstances. I also like Kurt's work because of its deep interest in internals. In Kurt's case this is involved with block and data storage internals. Kurt has developed a tool originally called jDUL and now called DUDE that mirrors the usefulness and functionallity of tools such as DUL used by Oracle consultants for recovering databases that have crashed and cannot be recovered in any other way. I am particularly interested in this area and have blogged on it a few times in the past because of the security connections with Oracle Forensics. A number of people have been talking about block internals because of forensics with the purpose to find deleted data as evidence. Whilst this is great and a really useful move forward in security terms for the database it is "old technology" as people like Kurt and a few others around the such as Lou Fangxin of AnySQL.net who has a similar http://www.anysql.net/en/aul.html - (broken link) DUL like tool called AUL have been doing this for 7 or 8 years and have clearly got a much deeper understanding of the data storage and structure.

I have added Kurt's blog to my Oracle blogs aggregator and I have also added A Arju's blog found via Kurt's aggregator as it also contains some posts about block internals.

There has been a number of emails posted to the bugtraq and full-disclosure mailing lists in the last few days detaling some of the vulnerabilities fixed in the recent Oracle Critical Patch Update July 2008. It is worth detaling some of these here. Most customers who are interested in Oracle security and the dreaded CPU cycle of release/test/patch/regression test and wait for the next one download the CPU advisory, they download the patch and read all the data supplied by Oracle.

From my experience most do not go further and seak out the advisories or additional details released by some of the researchers who found the bugs and also some that want to release exploits. This is important to do, not because I want to promote hacking but because I want to promote education. Customers of Oracle who download Oracles advisory are made aware that its the true source which is fine, it is. But we should be aware of what other people write and release whether they are "true" sources also or not. This is the information that someone who wants to crack your database could start with. It is the DBA's and security persons responsibility to understand the level of data and information out there. I am not suggesting to run any exploits or hacks but to understand whats out there, what someone could download and run against your own databases. If you understand then you have a better chance to make the database secure.

In the case of the CPU July 2008 there are a few advisories we can mention here. The first post i came across was by Andrea Purificato also known as Bunker who released details of cross site scripting in the package procedure PORTAL.WWPOB_HOME_PAGE.POPUP_NAME. The details are here.

There are three advisories released by iDefense (reported and discovered by Joxean Koret). The first is "Oracle Database Local Untrusted Library Path" which is an exploit to gain root in the extjob binary which is suid root. The second is "Oracle Internet Directory Pre-Authentication LDAP DoS Vulnerability" which is a bug in Oracles LDAP implemention that doesnt require authentication where by a crafted LDAP request can dereference a NULL pointer and cause the LDAP handler process to crash causing a Denial of Service. The third is "Oracle Database DBMS_AQELM Package Buffer Overflow Vulnerability" which is a SQL buffer overflow exploit.

HP have also released an advisory "HPSBMA02133 SSRT061201 rev.9 - HP Oracle for OpenView (OfO) Critical Patch Update"

Finally quite interestingly Joxean Koret has also released a seperate advisory for one of the iDefense bugs he reported "Oracle Database Local Untrusted Library Path Vulnerability" that also details the root user privilege escalation reported earlier. This advisory has a lot more detail than the iDefense one and includes exploit code. This is an interesting exploit as a multistaged attack is possible and this could be done remotely through the database using a number of techniques often caused by bad configurations.

As I said be aware of what people publish, this information is used by people to experiment, test and could be used against you. Be aware of whats published so that it can help you assess the risks of patching or not patching.

I wrote this last night but then my email connection failed (the ISP must have been doing maintenance) so could not send before i needed to sleep. I am teaching my two day class "How to perform an Oracle database security audit" today and tomorrow but can send this via 3g/gprs (great invention!) during the break..

Alexandr Polyakov posted a note to the bugtraq mailing list showing some example code (repeated here):

"create or replace procedure sh2kerr_num_proc is
stmt varchar2(2000);
n number:=dbms_random.value;
begin
stmt:='select object_name from all_objects where object_id = ' || n;
execute immediate stmt;
end;
/

--------------
TEST:

SQL> ALTER SESSION SET NLS_NUMERIC_CHARACTERS = '''.' ;
Session altered.

SQL> select dbms_random.value from dual;
VALUE
----------
'763871688
SQL> exec sh2kerr_num_proc
BEGIN sh2kerr_num_proc; END;

*
ERROR at line 1:
ORA-01756: quoted string not properly terminated"

David responded in the same thread to say that he did cover NLS_NUMERIC_CHARACTERS which he did, as i remember from reading it at the time but points out here that Alexandr has identified a specific attack vector in DBMS_RANDOM. I do check for use of this package in my security audits already so pick up its use anyway but its useful to have more "ammunition" in terms of why its use is an issue in addition to my existing arguments against its use.

Then David has posted another post to the bugtraq list showing that to exploit lateral SQL injection you do not need the ALTER SESSION privilege. here is the example from the mailing list email:

"C:\>sqlplus /nolog

SQL*Plus: Release 11.1.0.6.0 - Production on Fri Jul 18 14:47:17 2008

Copyright (c) 1982, 2007, Oracle. All rights reserved.

SQL> connect testuser1/testuser1
Connected.
SQL> select * from session_privs;

PRIVILEGE
----------------------------------------
CREATE SESSION

SQL> alter session set sql_trace = true;
alter session set sql_trace = true
*
ERROR at line 1:
ORA-01031: insufficient privileges

SQL> alter session set nls_date_format='"'' and myfunc()=1--"';

Session altered.

SQL> select sysdate from dual;

SYSDATE
------------------
' and myfunc()=1--

SQL>"

I was of course aware of this for many years but didn't connect this to David's paper at the time. I also just did a check search on google to see if I have mentioned this before but I haven't. I am surprised as I regularly have to actually demonstrate this to clients (not the exploit David mentions but the fact that the system privilege is not necessary). There are many things, many bad things you can do with the ALTER SESSION privilege, one such example is stealing data without access to the actual table. I always recommend to clients that they revoke ALTER SESSION from database accounts, they normally respond that they cannot because of x, y and z. I then need to demonstrate in SQL*Plus that ALTER SESSION is not actually needed to run most ALTER SESSION commands. It is needed to set SQL_TRACE and also to issue events. These are particular things we don't want people to do in normal production databases for security reasons. On the same veign as a corresponding example the ALTER USER command also works without the ALTER USER system privilege. A user can issue this command against their own account without the system privilege but not against another account.

I always mention these inconsistencies in my training class. A system privilege such as ALTER SESSION can be used for many things but control cannot be applied to the individual things allowed for that privilege if the system privilege is granted unless its exposed via a PL/SQL procedure but then the privilege would not be granted directly to the end user anyway so its not restricted at the "end user"/"privilege" level but via an interface level. Oracle would argue that the privilege is exposing elements of session settings which is fine but from a security perspective at least different things (elements of syntax) expose different risks.

The second level of inconsistency is the silent use of privileges such as ALTER SESSION and ALTER USER in controlled circumstances. This area needs to be better controlled, this functionallity may have been added to allow use of commands without the need to expose the dangerous parts (setting trace) but there is inconsistency there now and certainly from my experience over many years people are often not aware of this as I have to explain this in customer audit reports or even demo to the DBA's that ALTER SESSION does work without the privilege or connect role.

One thing I forgot to mention the other day in my post July 2008 Critical Patch Update is out - a remote un-authenticated exploit revealed is that one of the major changes you will notice with this CPU is that Oracle have started to identify each vulnerability with a CVE-ID number. The reason Oracle can do this is because they have become a candidate naming authority and are now allowed to issue unique numbers for each vulnerability. Whilst as Eric Maurice points out in his post July 2008 Critical Patch Update Released Oracle's own advisory is the primary source for details of Oracle vulnerabilities this change will certainly allow all other sources to report further details about vulnerabilities with consistency that can be tracked back to Oracles own advisory.

This is a good step in my opinion and should allow some emphasis of consistency. Duncan has told me that this change was made due to customer feedback and took quite some efforts to set up. I think we should acknowledge that Oracle do listen to customer feedback on CPU's and do want to make the whole process better for customers if they can. I am talking to customers of mine about this to get opinions, I already had a chat on Wednesday with one person who welcomed the changes.

I would like to hear others opinions here about this change, comments are open!

Sentrigo have released a new version of Hedgehog called vPatch.

Basically, it’s the same Hedgehog product but without the ability to create custom policies. After installation, without any configuration by the customer, Hedgehog vPatch will protect the database from known (and some 0day) attacks. This will help the customers to bridge the gap between CPU release and actual deployment.

From a commercial point of view, this offering is subscription based and costs $750 for a yearly subscription.

From my companies perspective I am excited as the UK reseller for Sentrigo as I have already said in a post "Sentrigo Hedgehog" that I am impressed by this product.

Everywhere I go, people engage me in conversations around CPU's and application of CPU's. In my experience it is getting better but let's not get carried away, most people are not patching quickly or at all. There is a change in direction but it is like a supertanker changing direction. Whilst i agree that the best option is to patch we have to be realistic and note that people do not patch or do not patch quickly so a product like vPatch is a good solution.

If anyone has any questions either about the enterprise version or the new vPatch then please let me know, also please feel free to download a free 14 day trail copy of the enterprise edition and see how easy it would be configure and use in your own organisations.

I covered the pre-release announcement for the July 2008 Critical Patch Update (CPU) here a few days ago in a post titled "Oracle Patch Tuesday Is Coming". Nothing new and major this time from the perspective of the pre-release report. I was intrigued when I looked at google news today and saw very few news reports so far on the latest in the long line of CPU releases. The pre-release note posted a week ago attracted at least 45 news reports according to Google but the actual release had 4 when i looked this morning (I guess its increased by now).

This is interesting, is it because these patches (in the scale of Oracle security things) is getting less significant, or maybe people are not as excited as they have been in the past as there are no directly exploitable database flaws this time without authentication? - who knows.

Oracle's advisory is released as a page titled Oracle Critical Patch Update Advisory - July 2008. The things of interest are that there are a few new names credited on the advisory that are not usually there and also that Laszlo has been post-credited for a fix delivered in the January CPU. The types of fixes / bugs are similar to those reported and fixed in previous CPU's.

The interesting point is that David Litchfield has yesterday released an advisory for a bug he reported on 9th Oct 2007 where the application server can be expolited remotely by an un-authenticated attacker that allows full control to be gained of the backend database server remotely from a webserver. The details posted by David to various lists are repeated here as a quote:

"Oracle Application Server installs a number of PLSQL packages in the backend
database server. One of these is the WWV_RENDER_REPORT package and it is
vulnerable to PLSQL injection. This package uses definer rights execution
and therefore executes with the privileges of the owner, in this case the
highly privileged PORTAL user.


Specifically, the SHOW procedure takes as its 2nd argument the name of a
function to execute and this is embedded with a dynamically executed
anonymous block of PLSQL without first being sanitized. Because it is a
block of anonymous PLSQL, an attacker can exploit this flaw to run any SQL
statement, for example, create new users, grant dba privileges, delete or
modify data. This is achieved by wrapping the statement(s) within an
"execute immediate" statement and specifiying the autonomous_transaction
pragma."

This is potentially dangerous for anyone who understands this can easily exploit it based on the information delivered to the full-disclosure list and especially if the CPU is not applied.

I am on the train whizzing back to York at around 120mph after being down in sunny London all day at the UKOUG Archive and purge special event conference. I was presenting there on the subject of archive and purge in a security context. The event was at the Radission SAS Portman in Portman Square just off Oxford street and was well attended. I had some good chats with people there on a wide range of Oracle security subjects.

It is interesting to take note that there is an ever increasing interest in Oracle database security and that people are becoming more aware of the risks to data day by day, event by event. This is good, the message is getting through and people are starting work on securing data at its source, in the database. More on this tomorrow, I have a half written post developed on the back of a forum post about the movement in interest in Oracle security.

My presentation was a new one for this event and the slides can be downloaded from my Oracle security white papers page. It is the top entry (obviously now, if you are reading this some time later then scroll down a bit and search for it). There are two versions as usual, the full one slide per page and the smaller (to download) 6 slides per page version.

This was a very interesting subject for me and I wanted to get across two important messages. These are:

• Consider archiving and purging of security data such as audit trails and logs


• Consider the security of archived business data (and also security data)
  

These are important for me as they fall into a class of issue I see more and more. That is the fact that often when there is security of specific data implemented its often very focused. I.e if you secure the credit card data, you secure the credit card table only and not all the other places the credit card data exists in your database and outseide of it. Archive data falls exactly into the same space and issue.

It was a good event, London was hot, now I am off home to wait for the July 2008 CPU to be available later this evening UK time.

Laszlo Toth has released a new version of his famous Oracle password cracker woraauthbf. This is version 0.22. The main page for the woraauthbf password cracker describes the tool and its use. http://www.soonerorlater.hu/download/woraauthbf_src_0.22.zip - (broken link)The latest C source code can be downloaded here and the latest binary compiled version for Windows can be downloaded here.

I will summarise the changes (taken straight from Laszlo's site with no change here):

"The 0.22 has some speed advancement because of the prehash implementation and has some usefull changes:

• Prehash implementation in the brute-force mode of the password hash.


• Prehash implementation in the dicitonary mode of the password hash (if the username len > 4)


• It saves the list of the index of the found passwords, so you can use --prev paramter to leave out the already cracked passwords from a previous session. In the session continue mode (-s), it loads the results automaticly.


• The order in the permutation engine was changed to follow a more logical way (thanks for Pete Finnigan suggesting it).


• The permutation engine has more parameters that controls which permutation should be included.

It is strongly recommended to use this new release. The list of some repaired bugs can be found here (thanks Michael Donnerer for reporting them). This is still an early release, so it needs massive bug hunting and code cleaning."

This is a worthwhile release to download and use at least for the speed increases. I have used Laszlo's cracker for quite some time now on professional database audits and always found it a useful tool.

I just did some simple tests comparing version 2.1 and version 2.2 of Laszlo's cracker. The first picture shows version 2.1 running for a single password using brute force. I ran the cracker for around 3 minutes to let it speed up and show a reasonable average:







I then ran the new woraauthbf cracker, version 2.2 and did exactly the same test:







The results are as expected and much faster than the earlier version. We see an increase in speed from 1.15 Million hashes a second to 1.4 million hashes a second. This is a 22.45% speed increase on my laptop. Quite impressive Laszlo!

The speed increase will not be as impressive for dictionary attacks as the word order cannot be guarenteed in a dictionary file to take full effect of the pre-hashing implemented by Laszlo.

I saw a news post the other day via google and made a note to mention it here as its a very interesting development. The post is titled "nCipher to Provide Encryption Key Management for Oracle Database 11g"

"MILPITAS, Calif., Jul 07, 2008 (BUSINESS WIRE) ----nCipher plc (LSE:NCH), a global leader in protecting critical enterprise data, today announced its nShield and netHSM key management solutions are now integrated with Transparent Data Encryption, part of Oracle Database 11g Advanced Security option. The combination of Oracle Transparent Data Encryption and nCipher's secure key management systems provides customers with the highest level of data security assurance and enables compliance with even the most rigorous regulations and industry standards, including the Payment Card Industry Data Security Standard (PCI DSS)."

This is very interesting on a number of levels. The first is that my extensive experience with encryption in Oracle databases and with getting involved with my clients solutions at all levels from design, development, integration, review and more for database encryption and TDE is that the key problem (pun intended) for everyone is the issue of keys, how to manage them, cycle them, protect them and more. I am really glad to see that Oracle and nCipher have got together in this way for TDE (Transparent Database Encryption) BUT....

Second point... I would have liked to see some co-operation or something much better from Oracle in the same area for the people who need to encrypt data in the database itself. TDE is fine to protect data at rest but its not a complete solution. PCI DSS 1.1 (I am paraphasing from memory here so don't shoot me down) states that only those people who need to see credit card PAN's should see them. Solutions around this include exposing parts of the PAN to all, different hashes searches, masking the PAN, workflow(authorisation for CoI and SoD issues) and more. In other words if a person (an employee) should be able to see the PAN, the application should call upon the database to decrypt the PAN and return it to their screen, for others who should not see it, it should refuse to return it or mask it or... in other words there is a gap, TDE is fine at encryption at rest but anyone with a SQL*Net connection to the database or application access can in a lot of cases query up PAN's and TDE doesn't stop this (hence the transparent in the name). For this you can have a whole host of solutions, database encryption , middle teir encryption, application encryption, RBAC, workflow....... lots of soltions.

What I would like to see is a simple in terms of easy to use/deploy key management solution for the database for use with say DBMS_CRYPTO, it should handle key storage, retrieval, cycling, managment, change on threat of breach, not cache..... in otherwords solve the main issues for those people who do use dbms_crypto in the database. There are solutions out there of course already but not something from Oracle, in the database or rather made to work easily with DBMS_CRYPTO.. oh, and i almost forgot, not as part of the ASO as most sites i work with don't deploy ASO almost exclsuively on cost grounds. Most agree the usefulness of ASO but don't want / or cannot justify the cost.

Well its been a while since my last blog post, it has been a hectic few weeks workwise, so little time to clear emails, blogs and all those things I would like to do but cannot because work gets in my way..

The next in the line of the Critical Patch Updates (CPU) July 2008 for the Oracle product stack is due next Tuesday, the 15th of July. The pre-release announcement was released last Tuesday, titled "Oracle Critical Patch Update Pre-Release Announcement - July 2008" and it details a potential tally of 45 fixes across a very wide range of products. The database layer is my particular sphere of interest and there are 11 fixes in the database, this time none that can be remotely expolited without a password, this doesn't imply or deny if any are remotely exploitable with a password!. The highest CVSS score is 6.5 which is quite high considering the methods used to calculate it. The interesting ones are "authentication" as that implies a fault in the authentication mechanism, presumably from the above statement that is not expliotable until after the authentication completes, i.e. you need a password. Core RDBMS sounds interesting as does database vault. The others could in most cases be PL/SQL based issues, we will need to wait and see next week.

There are a whole raft of news reports about the same pre-release document mostly all summarising whats in it. You can query Google for "Oracle Security" in the news and read them.