Yesterday Oracle announced via the FAQ - Note 282108.1 created for the first monthly security patch release - Security Alert #68 that the Oracle clients are also vulnerable. Whether the client also needs to be patched has also been discussed a few times over the last few weeks on lists such as ORACLE-L and c.d.o.*.
Point 21 in the above FAQ discusses the question "is the Oracle client also vulnerable because of the issues fixed in alert 68". It states that some of the issues addressed are also applicable to middle tier installations and also to client only installations. Basically a successful hack of the client will not get you into the database or its server if its been patched with alert 68 but the client is exploitable. Oracle have reduced the severity of the patch to 2 for clients and 2 for application servers if the application server has been patched.
Refer to the pdf on Oracle's OTN site available above for alert #68 and also the FAQ available only on metalink for more details
Blog
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.
Creating read only users
I see questions relating to creating read only users on the mailing lists and newsgroups very regularly and sometimes directly to my own mail box. I also see regularly a deep misunderstanding of how to do this and also more importantly how to do it securely.
Quite often someone will suggest granting SELECT ANY TABLE or will suggest solutions with no common sense like I saw today where one guy suggested granting the CONNECT role.
This tells me that there are two problems. First people do not understand what a read only user is, i.e. the assumption that the word CONNECT allows a user to connect and presumably read all data is obviously wrong. But granting CONNECT to a user in this scenario is also wrong as this role allows far too many create privileges as well as ALTER SESSION, not to mention the user created would not be able to see the data he or she needed. The second issue is with the sweeping grant of SELECT ANY TABLE. This is often done without considering the side effects of this.
more..
Quite often someone will suggest granting SELECT ANY TABLE or will suggest solutions with no common sense like I saw today where one guy suggested granting the CONNECT role.
This tells me that there are two problems. First people do not understand what a read only user is, i.e. the assumption that the word CONNECT allows a user to connect and presumably read all data is obviously wrong. But granting CONNECT to a user in this scenario is also wrong as this role allows far too many create privileges as well as ALTER SESSION, not to mention the user created would not be able to see the data he or she needed. The second issue is with the sweeping grant of SELECT ANY TABLE. This is often done without considering the side effects of this.
more..
Oracle Database 9i SQL Command Buffer Overflow Vulnerability
Security focus newsletter #266 included news of the above bug. This is fixed in Oracle alert #68 but Security Focus has assigned a specific BID number, 11120 to this issue because specific technical information has been released. This is one of the un-disclosed vulnerabilities in BID 10871 assigned by Security Focus to Oracle alert #68. This looks like its the buffer overflow in the built in function SYS_CONTEXT. Alexander Kornbrust has been credited with this vulnerability.
eweek article: Oracle Users Take Aim at High Costs, Security Silence
An interesting article posted yesterday to eweek and written by Lisa Vaas discusses the new report by Techtel Corp published earlier this month written by Mike Kelly that discusses features, service, support, standards and compatibility, vendor reliability and accountability, pricing and licensing. Mike Kelly said Oracle came out much lower on all the items being compared than IBM. The article is over two pages, http://www.eweek.com/article2/0,1759,1651206,00.asp - (broken link) page 1 and page 2. The second page will be of most interest to those with an interest in Oracle security.
Security is the latest concern for customers of Oracle Yuhanna says. The article discussed the first of monthly patch set releases and Craig Read suggests that most customers are disgruntled with Oracles lack of detail and information on the security patch set. The article makes interesting reading, it goes on to say that 90% of the user community say they were not informed about the patch set release and were unhappy about the lack of detail.
Security is the latest concern for customers of Oracle Yuhanna says. The article discussed the first of monthly patch set releases and Craig Read suggests that most customers are disgruntled with Oracles lack of detail and information on the security patch set. The article makes interesting reading, it goes on to say that 90% of the user community say they were not informed about the patch set release and were unhappy about the lack of detail.
KK Mookhey writes about auditing Oracle security
KK Mookhey who is based in India and is CTO of Network Intelligence India Pvt. Ltd has written an excellent paper about auditing an Oracle database, this was published sometime ago but is still generating interest and quite a lot of people have not seen or read it yet so I thought I would talk about it here. The paper is called "Auditing Oracle Security" and is available here.
This paper is very well written and covers a good degree of the ground to get anyone started on trying to secure a database. It covers the installation, parameters, users and profiles, default accounts, how to use auditing, even defunct accounts, password management, roles and privileges and of course the listener. KK also talks about controls within the database such as the product user profile functionality for controlling access through SQL*Plus. He covers Virtual Private Databases (VPD) and encryption. KK also gives good advice on how to focus any audit of an Oracle database.
This is a good overall discussion on Oracle security and anyone starting to think about auditing an Oracle database should read it before delving into more detailed discussions and tools.
This paper is very well written and covers a good degree of the ground to get anyone started on trying to secure a database. It covers the installation, parameters, users and profiles, default accounts, how to use auditing, even defunct accounts, password management, roles and privileges and of course the listener. KK also talks about controls within the database such as the product user profile functionality for controlling access through SQL*Plus. He covers Virtual Private Databases (VPD) and encryption. KK also gives good advice on how to focus any audit of an Oracle database.
This is a good overall discussion on Oracle security and anyone starting to think about auditing an Oracle database should read it before delving into more detailed discussions and tools.
The SANS S.C.O.R.E. Oracle security checklist has been updated
The SANS Institute has a set of security checklists based around their S.C.O.R.E. initiative. These are a set of free checklists that are being developed by SANS where each document has a lead developer who is an expert in the particular area or particular software in respect to the security issues. These are a great resource for anyone wanting to secure a particular piece of software or application.
The Oracle checklist is based around the SANS Oracle security step-by-step guide and reflects the thinking and research of many Oracle experts who know how to secure Oracle databases. The document for Oracle has just been updated to version 2.0 to reflect the changes made in the newly released version of the step-by-step book. I was the author of the book and the S.C.O.R.E. document and I am also just been appointed as the lead developer / maintainer of the checklist by SANS.
The Oracle S.C.O.R.E. checklist can be found here
The Oracle checklist is based around the SANS Oracle security step-by-step guide and reflects the thinking and research of many Oracle experts who know how to secure Oracle databases. The document for Oracle has just been updated to version 2.0 to reflect the changes made in the newly released version of the step-by-step book. I was the author of the book and the S.C.O.R.E. document and I am also just been appointed as the lead developer / maintainer of the checklist by SANS.
The Oracle S.C.O.R.E. checklist can be found here
Arup Nanda is interviewed about the Oracle security patch nightmare
I just came across an interview by Robert Westervelt a news writer for SearchOracle.com that was written yesterday 21-09-04. The article is here. Arup is a very well known Oracle security expert and has written an excellent book "Oracle privacy security auditing" published by Rampant press which is all about getting an Oracle database to comply with the HIPAA, SO and GLB acts in the USA. The book is very well written and covers good ground. I plan to review it in the near future here. Arup is interviewed about the issues with the first of the new monthly patch releases from Oracle, the infamous alert #68. His concerns centre on the fact that Oracle have released very little information about the large number of security fixes this patch addresses and the fact that this makes it hard for customers to know which functions of Oracle need patching.
I agree with Arups concerns whole heartedly. I know now that a lot of the actual vulnerabilities are described in much more detail on the researcher’s sites who found the issues. Take a look for instance at the extra information detailed on my alerts page for the bugs I found and those Alex Kornbrust found.
I can also only agree with Arup that I hope Oracle provide better information on future alerts so that DBA's can understand the risks of applying or not immediately applying the patches.
I agree with Arups concerns whole heartedly. I know now that a lot of the actual vulnerabilities are described in much more detail on the researcher’s sites who found the issues. Take a look for instance at the extra information detailed on my alerts page for the bugs I found and those Alex Kornbrust found.
I can also only agree with Arup that I hope Oracle provide better information on future alerts so that DBA's can understand the risks of applying or not immediately applying the patches.
Truncating the audit trail
Today there has been a question posted to comp.oracle.databases.misc (The thread is here) asking about deleting or truncating the audit trail when its stored in the SYS owned table AUD$. The poster wanted to know about creating a procedure to periodically delete or truncate the contents and about creating that procedure as the user SYS.
I answered with quite a log post detailing the issues of privileges and also showing a short example if creating a procedure as a user that has had its privileges removed later so it cannot be logged in with and then calling that procedure from another user to encapsulate the privilege.
You can read my post by clicking "more".
more..
I answered with quite a log post detailing the issues of privileges and also showing a short example if creating a procedure as a user that has had its privileges removed later so it cannot be logged in with and then calling that procedure from another user to encapsulate the privilege.
You can read my post by clicking "more".
more..
Are your system triggers firing?
An interesting question was posted on the comp.databases.oracle.server newsgroup a few days ago that asked a question about why the posters AFTER CREATE ON SCHEMA trigger was no longer firing. A link to the thread can be found here.
So how does this relate to Oracle security? Quite often the system trigger facilities are used as an additional audit trail or as a mechanism to prevent certain actions taking place or as part of a virtual private database solution. Let's give some examples. A logon trigger can record details of each user connecting to the database into an additional audit table created for the purpose. Quite often more detail can be recorded than with the conventional audit trail. A trigger could also fire when any DDL is issued and record that to an audit table for the purposes of managing change and detecting when it occurs. Also for instance a logon trigger could also be used to prevent certain applications or users from connecting to the database by checking certain session values as the user connects for instance for the program name or user name or IP Address. Also logon triggers can be used to set the correct context for a user as part of a virtual private database solution.
more..
So how does this relate to Oracle security? Quite often the system trigger facilities are used as an additional audit trail or as a mechanism to prevent certain actions taking place or as part of a virtual private database solution. Let's give some examples. A logon trigger can record details of each user connecting to the database into an additional audit table created for the purpose. Quite often more detail can be recorded than with the conventional audit trail. A trigger could also fire when any DDL is issued and record that to an audit table for the purposes of managing change and detecting when it occurs. Also for instance a logon trigger could also be used to prevent certain applications or users from connecting to the database by checking certain session values as the user connects for instance for the program name or user name or IP Address. Also logon triggers can be used to set the correct context for a user as part of a virtual private database solution.
more..
A new Oracle security based weblog
Hi,
Welcome to my new Oracle security related web log. I want this log to be a good source of Oracle security information for people who are interested in taking security seriously especially in relation to their databases. There is a growing interest in security in relation to databases in general and in Oracle security in particular. There are more and more papers being written and new products being released more and more regularly. I am not 100% sure about other logs out there but I think this could be the first web log aimed directly at Oracle security - let me know if I am wrong.
more..
Welcome to my new Oracle security related web log. I want this log to be a good source of Oracle security information for people who are interested in taking security seriously especially in relation to their databases. There is a growing interest in security in relation to databases in general and in Oracle security in particular. There are more and more papers being written and new products being released more and more regularly. I am not 100% sure about other logs out there but I think this could be the first web log aimed directly at Oracle security - let me know if I am wrong.
more..
September 2004
- A new Oracle security based weblog - 09/20/2004 by 09/20/2004
- Are your system triggers firing? - 09/21/2004 by 09/21/2004
- Arup Nanda is interviewed about the Oracle security patch nightmare - 09/22/2004 by 09/22/2004
- The SANS S.C.O.R.E. Oracle security checklist has been updated - 09/23/2004 by 09/23/2004
- KK Mookhey writes about auditing Oracle security - 09/24/2004 by 09/24/2004
- eweek article: Oracle Users Take Aim at High Costs, Security Silence - 09/25/2004 by 09/25/2004
- Oracle Database 9i SQL Command Buffer Overflow Vulnerability - 09/26/2004 by 09/26/2004
- Creating read only users - 09/28/2004 by 09/28/2004
- Oracle announce that clients also need patching for alert #68 - 09/30/2004 by 09/30/2004
Archives
Syndication
Powered by gm-rss 2.0.0
