The latest and greatest Critical Patch Update from Oracle was released last night along with the usual advisory. I talked about the pre-release note a few days ago here in a post titled "Oracle's October pre-cpu advisory is released". Oracles actual advisory is here. There is not much more to say now than there was for the pre-release note except that two things of note were in the advisory. The first is that there is a nice array of "names" in terms of number of people. There are just 38 bugs fixed over the whole array of products so there is a good cross reference of people to bugs. What does this mean? new people looking at Oracle security or just new people because some of the products are new to the process? remember the post "How many Security bugs are in the Oracle database software product set"? this also means that the number of actual bugs is bigger. All this sums up to good positive steps on Oracles product security; bugs are being tackled, people are interested in helping Oracle test their software..
The second thing of note for me is that is 6 bugs in the database with a CVSS of 10.0 on Windows and 7.5 on other OS's and also the problem that they are remotely exploitable without username/password. Anyway the interesting thing is the advice for workarounds; on average Oracle do not usually give workaround advice. In this case they say remove privileges or ability to access on the affected packages and also to restrict network protocols. Of course the primary advice is to apply the CPU.
Also Paul has released a new paper "Create table to OSDBA with reverse shell". Paul explains the how in the paper.
October 2009 Critical Patch Update is out; Paul has a paper on escalation to OSDBA
There has been 3 Comments posted on this article
October 23rd, 2009 at 06:17 pm
Pete Finnigan says:
Hi Dirk,
Thanks for your comment. I hope that Paul will drop by and answer your points himself.
cheers
Pete
October 23rd, 2009 at 10:23 pm
Pete Finnigan says:
Hi Dirk,
Point 1. About -R not working ~ please refer to line 1 of the last page which states "-R is just to get the external table to work". In other words you need to have an OPTION for the external table to work. It does not actually get used in this case. Did you test the code without a specified OPTION?
2. With regards paths ~ all paths can be specified as absolute as the script runs with the privileges of the oracle user. I tested the scripts thoroughly and they all worked fine for me. Try using absolute paths if you have problems with env vars.
3. Regarding execute unix os permission~ the top of the penultimate page states "--Note that even though the contents of the previously existing shell script on the OS have been
completely overwritten the OS file execute privileges stay the same on the new version of the script." the file is called previously_existing.sh . There will probably be an executable file in the OS directory if the DB directory is made executable as that is the point of doing so. Just need to list the contents as mentioned.
But do remember that the file does not need to be executable on Windows thus making this a more serious issue on Windows.
The point of this paper is that granting execute on a directory to a user with create table is effectively granting osdba because once the script is on the os it acts with oracle's privs, thus bypassing all DB directory restrictions. This makes revoking public execute on utl_file a must and should be done by default given the new directory execute permission in 11g. Everyone I know agrees on this point. So I am confident about the validity of the argument, but it is all the better for public scrutiny. Thanks for your feedback Dirk.
Cheers,
Paul
October 23rd, 2009 at 01:57 pm
Pete Finnigan says:
Hi Pete,
Paul's paper is really interesting, but there some small problems:
1. As Paul declare in his paper it should also work on UNIX platforms is not correct. At first the Options Flag '-R' in the external table definition can't be used. Secondly the PL/SQL Block to create the shellscript are creating a correct shellscript, but not with executable rights :-( So it's not working.
2. On Windows it's working only if add in the creation of the batch-file some environment variables: set ORACLE_HOME=xxx / set ORACLE_SID=xxx / set PATH=%ORACLE_HOME%\bin;%PATH% and then the batchfile is working correctly. The same environments you should also set on the UNIX platforms, but then still the problem with the executable permissions on the shellscript is existing.
Cheers
Dirk