Auditing an Oracle database for security issues is very important. PeteFinnigan.com provides all of the information and tools that you will need Click here for details of PeteFinnigan.com Limited's detailed Oracle database security audit service Click here for details of PeteFinnigan.com Limited's Oracle Security Training Courses
There are 77 visitors online    
Cookie Policy:We only use essential cookies on small sections of this website. For details see here.

Pete Finnigan's Oracle security weblog


Home » Archives » October 2009 » October 2009 Critical Patch Update is out; Paul has a paper on escalation to OSDBA

[Previous entry: "Health Data Theft"] [Next entry: "Mary Ann Davidson fields security questions at Open World"]

October 2009 Critical Patch Update is out; Paul has a paper on escalation to OSDBA

October 21st, 2009 by Pete


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.

There has been 3 Comments posted on this article


October 23rd, 2009 at 01:57 pm

Dirk Nachbar 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



October 23rd, 2009 at 06:17 pm

Pete 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

Paul M. Wright 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 2009
SMTWTFS
    123
45678910
11121314151617
18192021222324
25262728293031

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.

Weblog Home
Weblog Archives


Home
Oracle Security Tools page
Oracle security papers
Oracle Security alerts

Web Development
SQL Server Security

RSS 1.0 FEED
RSS 2.0 FEED
Atom 0.3 FEED
Powered by gm-rss 2.0.0


Valid XHTML 1.0!