rmoff

August 4, 2011

Security issue on OBIEE 10.1.3.4.1, 11.1.1.3

Filed under: bug, obiee, security — rmoff @ 10:00

July’s Critical Patch Update from Oracle includes CVE-2011-2241, which affects OBIEE versions 10.1.3.4.1 and 11.1.1.3.
No details of the exploit other than it “allows remote attackers to affect availability via unknown vectors related to Analytics Server.”

It is categorised with a CVSS score of 5 (on a scale of 10), with no impact on Authentication, Confidentiality, or Integrity, and “Partial+” impact on Availability. So to a security-unqualified layman (me), it sounds like someone could remotely crash your NQSServer process, but not do any more damage than that.

Patches 11833743 and 11833750 for 10.1.3.4.1 and 11.1.1.3 respectively.

February 23, 2011

Changing LDAP settings in an OBIEE RPD with UDML

Filed under: hack, ldap, obiee, udml — rmoff @ 17:06

A chap called Kevin posted a comment on a previous posting of mine asking

did you ever come across anything that could be used to change the LDAP server settings from a command line (admintool.exe, UDML, or otherwise)?

I did a quick play around with some UDML and it appears that you can.

Set up the initial LDAP server definition in the RPD

First I added a dummy LDAP server to samplesales.rpd:

A LDAP server added to samplesales.rpd

Then save and close the RPD.

Export the RPD to UDML format, and isolate the LDAP server UDML definition

Next open up a command prompt and run the following, which will export the UDML for the whole RPD:

c:\oraclebi\server\bin\NQUDMLGen.exe -U Administrator -P Administrator -R c:\oraclebi\server\repository\samplesales.rpd -O c:\scratch\udml.txt

Running the export of UDML

Open up the generated UDML in your favourite text editor. In the above example, it will have been written to c:\scratch\udml.txt.

Do a search for the name of your LDAP server, and you should hopefully find a line like this:

DECLARE LDAP SERVER "My LDAP server" AS "My LDAP server" UPGRADE ID 80295

What you do now is remove all the rest of the RPD UDML, so cut from the beginning of the file up to the DECLARE LDAP SERVER, through to the next DECLARE statement. You should end up with something like this:

Example UDML for the LDAP server definition

Make the required LDAP server change in the UDML

On a copy of the UDML extracted above, make the required changes to the LDAP server definition.
For this example, let’s imagine we’re moving the RPD to use a pre-production LDAP server.
In a copy of the original udml.txt file, now called ldap_preprod.udml, I’ve simply amended the HOST NAME field:

HOST NAME 'ldap.preprod.server.com'

Save the changed file (ldap_preprod.udml in my example).

Apply the LDAP server change to the RPD

Back at the command line, and this time NQUDMLExec

c:\OracleBI\server\Bin\nQUDMLExec.exe -U Administrator -P Administrator -I c:\scratch\ldap_preprod.udml -B c:\OracleBI\server\Repository\samplesales.rpd -O c:\OracleBI\server\Repository\samplesales.preprod.rpd

This applies the UDML in the file specified by “-I” (c:\scratch\ldap_preprod.udml) to be applied to “-B” base repository file (c:\OracleBI\server\Repository\samplesales.rpd) and write the output to “-O”, a new repository file (c:\OracleBI\server\Repository\samplesales.preprod.rpd).

Open up the new RPD in Administration Tool and check the results of your handiwork:

LDAP settings showing the change made in the UDML file

Further reading

UDML in OBIEE is nothing new, and there are some very good articles to read if you want to understand more about it:

Footnote

All this can be done on Unix too, just make sure you have set your OBIEE environment first with sa-init.sh (or sa-init64.sh) before calling nqudmlgen / nqudmlexec

Whether Windows or Unix, make sure you work on a copy of your RPD, because you might corrupt it otherwise. I’m pretty sure some UDML hacking is unsupported, so use this at your own risk. And did I mention, work on a copy of your files and take backups.

From a note that I wrote last year it looks like UDML is on its way out and an XML-based version on its way in for OBIEE 11g.

The code snippets assume that you have OBIEE installed to c:\OracleBI – amend the path as necessary if you have it elsewhere. You’ll always find NQUDMLGen & NQUDMLExec in <wherever you installed OracleBI>/server/Bin (or Bin64).

September 2, 2010

Misbehaving Informatica kills Oracle

Filed under: bug, informatica, obia, ORA-28001, oracle, security — rmoff @ 13:23

This problem, which in essence is bad behaviour from Informatica bringing down Oracle, is a good illustration of unintended consequences of an apparently innocuous security setting.
Per our company’s security standards, database passwords expire every 90 days. When this happens users are prompted to change their password before they can continue logging into Oracle. This applies to application user IDs too.
It appears that Informatica 8.6.1 HF6 (part of OBIA 7.9.6.1) doesn’t handle an expired password well, spawning multiple connections to the database, eventually bringing Oracle down through memory SWAP space exhaustion.

As a side note, one of our DBAs has been investigating how to prevent a client connection accidentally (through bad coding) or maliciously (DoS) bringing down Oracle in this way, his findings are documented here.

Investigation

As the introduction to any good IT horror story goes … “Everything was running fine; nothing had changed”.

Then our monitoring showed swap space usage on our Oracle 11g database server increasing, and soon after Oracle crashed. The DBAs restarted Oracle, but shortly after the swap space usage was on its way up. The unix tool Glance showed a lot of Oracle processes on the box.

Database

Our Informatica repository user expired on the day on which this happened (Aug 27th):

select username, account_status, expiry_date from dba_users

USERNAME                       ACCOUNT_STATUS                   EXPIRY_DATE
------------------------------ -------------------------------- ---------
INF_REPO                       EXPIRED                          27-AUG-10

When a user ID expires an ORA-28001 is given at login:

sqlplus INF_REPO/password

SQL*Plus: Release 11.1.0.7.0 - Production on Thu Sep 2 08:40:17 2010

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

ERROR:
ORA-28001: the password has expired

Changing password for INF_REPO
New password:

This is the throughput figures for Oracle from Enterprise Manager, note the Logons rate starting to increase at c.13:30 (The rate at 03:00AM is representative of the usual logon load on the database):

Server

Note SWAP space increase (dark blue line) at c. midday (nb GMT/BST mean not all the graphs will align):

Database server metrics

Database server metrics

Note number of Alive Oracle processes (faint yellow line!):

Database server metrics - Oracle application only

Database server metrics - Oracle application only

Informatica

In the Informatica exceptions.log and node.log are the initial errors:

ERROR [Master Elect Data Writer] [DOM_10162] An exception occurred while updating the master election row.
java.sql.SQLException: [informatica][Oracle JDBC Driver]No more data available to read.

ERROR [Master Elect Data Writer] [DOM_10162] An exception occurred while updating the master election row.
java.sql.SQLException: [informatica][Oracle JDBC Driver][Oracle]ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
HPUX-ia64 Error: 2: No such file or directory

ERROR [Master Elect Data Writer] [DOM_10162] An exception occurred while updating the master election row.
java.sql.SQLException: [informatica][Oracle JDBC Driver][Oracle]ORA-28001: the password has expired

Followed by the repeated error approximately every ten seconds:

ERROR [Master Elect Data Writer] [DOM_10162] An exception occurred while updating the master election row.
java.sql.SQLException: [informatica][Oracle JDBC Driver][Oracle]ORA-28001: the password has expired

There are also final errors in the log, occuring once only just after midnight:

FATAL [Domain Monitor] [PCSF_10374] Failed to persist [CpuUsageSummary] with error [[informatica][Oracle JDBC Driver]No more data available to read.].
FATAL [Domain Monitor] [PCSF_10374] Failed to persist [RepoUsageSummary] with error [[informatica][Oracle JDBC Driver]No more data available to read.].

After these Informatica shut down.

Theory

This is what I think is happening:

  • Informatica has a polling component (“[Master Elect Data Writer]”) that updates a database table (part of the Informatica repository) every minute
  • Once the user has expired, Informatica gets ORA-28001: the password has expired when it tries to connect
  • Informatica does not handle ORA-28001 correctly
  • It appears that it leaves the connection open
  • It then retries a few seconds later
  • The connections stack up, each taking swap space allocated to the Oracle process that the connection spawns
  • Eventually the server runs out of resource and Oracle crashes
  • At midnight another Informatica component (“[Domain Monitor]”) tries to update a database table (part of the Informatica repository), and gets the ORA-28001 error.
  • This second component (“[Domain Monitor]”) correctly takes the error as fatal and aborts the Informatica server process

Resolution

In my opinion, Informatica should consistently treat ORA-28001 as fatal.

At the very least, if Informatica isn’t treating ORA-28001 as fatal it should close the connection to the database correctly.


An update from Informatica here

May 17, 2010

Validating EBS-BI authentication, without BI

Filed under: obia, obiee, security — rmoff @ 15:42

Troubleshooting EBS-BI integrated authentication can be a tiresome activity, so here’s a shortcut that might help. If you suspect the problem lies with EBS then you can leave OBIEE out of the equation.

  1. Login to EBS
  2. Use FireBug or Fiddler2 to inspect web traffic as follows:
    1. Click the BI link from EBS
    2. Should be first a request to EBS server, which returns 302 and redirects to http://<bi server>:<port>/analytics/saw.dll?Dashboard&acf=101507310
    3. Record the value of acf (eg 101507310)
    4. Record the value of the cookie that’s passed to BI. It should normally match the EBS TNS name (but doesn’t have to). In this example it’s EBSBIS1A, and the value is _ACpwGUoeCKUX7GilVh7ZZKR:S
  3. Use sqlplus to open a connection to the EBS database using the ID that BI connects as (eg EBS_BI)
    $sqlplus EBS_BI/password@EBSDATABASE
    
    SQL*Plus: Release 11.1.0.6.0 - Production on Mon May 17 13:10:11 2010
    
    Copyright (c) 1982, 2007, Oracle.  All rights reserved.
    
    
    Connected to:
    Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options
    
    SQL> 
  4. Enter this statement, substituting values as appropriate
    call /* acf */ APP_SESSION.validate_icx_session(‘cookie value’); eg:
    SQL> call /* 101507310 */ APP_SESSION.validate_icx_session('_ACpwGUoeCKUX7GilVh7ZZKR:S');
  5. Expect to get:
    Call completed.
    
    SQL>
  6. If the cookie ID is invalid you’ll get
    ERROR at line 1:
    ORA-06510: PL/SQL: unhandled user-defined exception
    ORA-06512: at "APPS.APP_SESSION", line 315
    

    After writing this I discovered My Oracle Support article 758392.1 which has the same info plus a bit more.

March 5, 2010

Securing OBIEE Systems Management JMX for remote access

Filed under: jmx, obiee, security, systemsmanagement — rmoff @ 17:21

JMX

OBIEE’s Systems Management functionality exposes performance counters and the application’s configuration options through Java MBeans and optionally a protocol called JMX.

It’s extremely useful, and is documented pretty widely :

In this article I’m going to discuss the use of JMX to access these counters remotely, and a possible security issue that’s present in the BI Management Pack manual. The BI Management Pack is an add-on to Oracle’s Enterprise Manager / Grid Control for managing OBIEE, see Mark Rittman’s excellent guide on Oracle’s website.

Security Issue

To access Systems Management data remotely you need to start the JMX agent, having configured it for remote access first. However, if you are lazy, and/or follow the configuration in the BI Management Pack manual, and set com.sun.management.jmxremote.authenticate=false anyone can update your OBIEE configuration if they have network access to your server and a client for JMX (such as jconsole, part of standard java distribution) and time to guess the port number. This is not cool. Ever played with AUTHENTICATION=BYPASS_NQS?

The latest Java documentation (now with an Oracle logo!) does address this:

Caution – This configuration is insecure. Any remote user who knows (or guesses) your JMX port number and host name will be able to monitor and control your Java application and platform. While it may be acceptable for development, it is not recommended for production systems.

To be clear – if you’re not running the JMX Agent, this is all irrelevant. It’s only if you’re running it and haven’t thought through the consequences of the configuration.

Making the JMX Agent more secure

One way to secure the JMX agent is to use password authentication. The other is to set up SSL. The following demonstrates how to enable password authentication.

Please note – the following covers how to password-protect the JMX agent. It isn’t making it bullet-proof, and there’s no reason why a dictionary attack against it wouldn’t work as there’s no lockout. This also means it’s a good reason not to use a default username from the config files. Note also the following warning in the Java documentation: (if anyone can translate it into english I’d be grateful 😉 )

“WARNING: A potential security issue has been identified with password authentication for JMX remote connectors when the client obtains the remote connector from an insecure RMI registry (the default). If an attacker starts a bogus RMI registry on the target server before the legitmate one is started, then the attacker can steal clients’ passwords.”

To enable password authentication you need to edit three files.
The first file to edit is the agent script, runagent.sh. You’ll find this in $ORACLEBI_HOME/systemsmanagement.
By default, the file looks like this:

#!/bin/sh
# this is a template of runagent.sh to be used on Unix.
# The installer will fill in JAVA_HOME, SAROOTDIR, and SATEMPDIR

export JAVA_HOME=/usr/java/jdk1.6.0_17
export SAROOTDIR=/app/oracle/product/obiee
export SADATADIR=/data
export SATEMPDIR=/data/tmp
export UNIXPERFDIR=${SATEMPDIR}

java_cmd="${JAVA_HOME}/bin/java -Djava.library.path=${SAROOTDIR}/server/Bin -Dcom.sun.management.jmxremote -classpath analytics-jmx.jar:lib/xmlparserv2.jar oracle.bi.analytics.management.StandardConsoleAgent"

${java_cmd}

To enable remote access to the JMX agent you change the java_cmd to the following:

java_cmd="${JAVA_HOME}/bin/java -Djava.library.path=${SAROOTDIR}/server/Bin -Dcom.sun.management.jmxremote -Dcom.sun.man
agement.jmxremote.port=9980 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -
classpath analytics-jmx.jar:lib/xmlparserv2.jar oracle.bi.analytics.management.StandardConsoleAgent"

Note that jmxremote.authenticate is set to false. To secure the JMX agent you change it to true:

java_cmd="${JAVA_HOME}/bin/java -Djava.library.path=${SAROOTDIR}/server/Bin -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9980 -Dcom.sun.management.jmxremote.authenticate=true -classpath analytics-jmx.jar:lib/xmlparserv2.jar oracle.bi.analytics.management.StandardConsoleAgent"

Now note what JAVA_HOME is set to in the runagent.sh file (in the above example it’s /usr/java/jdk1.6.0_17). Navigate to this directory, and then to jre/lib/management. You should see these four files:

jmxremote.access
jmxremote.password.template
management.properties
snmp.acl.template

Create a copy of jmxremote.password.template to a file called jmxremote.password. Open the file and you’ll see two default users (or “roles”) as the documentation calls them.

$cp jmxremote.password.template jmxremote.password
$vi jmxremote.password
#
# Following are two commented-out entries.  The "measureRole" role has
# password "QED".  The "controlRole" role has password "R&D".
#
# monitorRole  QED
# controlRole   R&D

We’ll come back to this file in a moment. Now open jmxremote.access and you’ll see the access rights for the users (“roles”) in the password file are defined here:

#       "readonly" grants access to read attributes of MBeans.
#                   For monitoring, this means that a remote client in this
#                   role can read measurements but cannot perform any action
#                   that changes the environment of the running program.
#       "readwrite" grants access to read and write attributes of MBeans,
#                   to invoke operations on them, and to create or remove them.
#                   This access should be granted to only trusted clients,
#                   since they can potentially interfere with the smooth
#                   operation of a running program

So, now decide how you want to regulate access. I would strongly recommend that the only access available through remote JMX is readonly. Read/Write access to configuration needs to be through one auditable route, and I’d suggest this isn’t the best one. If that’s how we’re going to configure it, we set the files up like this:
(delete or comment out everything in the files first, having taken a backup first)
jmxremote.password:

jmxobiee  S3cur3Passw0rd

jmxremote.access

jmxobiee readonly

Finally, secure access to the password file so that it’s only readable by the application owner ID:

chmod 600 jmxremote.password

Now, go back to $ORACLEBI_HOME/systemsmanagement, and start the JMX agent:

nohup ./runagent &

(the nohup and & make it run in the background so it doesn’t quit when you exit your session)

Having started your agent, you can go to JConsole and login to it remotely.

See the document here for the full details of securing JMX, including use of SSL and alternative password file locations.

Using JConsole

JConsole should be in your PATH, so enter JConsole from Start -> Run (Windows), or alternatively find it in the bin directory of your JAVA home directory (Windows/Linux/Unix).

To see the OBIEE counters click on MBeans tab :

and then expand the “Oracle BI Management” folder:

You’ll notice if you’re connected as a readonly user and try to change any values you get an error:

When OBIEE is running you get some very detailed performance counters:

(If you only see Configuration folders within BI then it’s because OBIEE isn’t running 🙂 )

One nice thing you can do is see a graph of the metrics, by clicking on Attributes in the left tree, and then double-clicking on the number you want to graph in the right pane:

Footnote

I find the possibilities of the JMX interface to BI counters very interesting, and am surprised there is so little discussed about it. Maybe everyone else is merrily using it and feels no need to brag 😉

The counters in particular that BI Server exposes gives a peek under the covers of an application that has no detailing logging other than NQQuery.log. Using these counters through JMX we can look at things such as the current state of a connection pool, or the BI Server Cache.

Does anyone know of a freeware tool for collecting data from JMX? I know I could use the BI Management Pack but we don’t have it. JConsole or JManage give visualisation of the data realtime, but the latter is very rough around the edges.

January 22, 2010

How to resolve “[nQSError: 12002] Socket communication error at call=: (Number=-1) Unknown”

Filed under: config, obiee, security, unix, windows — rmoff @ 12:37

This error caught me out today. I was building a Linux VM to do some work on, and for the life of me couldn’t get the OBIEE Admin Tool to connect to the BI Server on the VM.

The error I got when trying to define a DSN on the Windows box was:

[nQSError: 12008] Unable to connect to port 9703 on machine 10.3.105.132
[nQSError: 12010] Communication error connecting to remote end point: address = 10.3.105.132; port = 9703.
[nQSError: 12002] Socket communication error at call=: (Number=-1) Unknown

This error means that the ODBC Driver for BI Server can’t communicate with the BI Server on port 9703.
99% of the time this question comes up on the forums it’s because the BI Server isn’t running, or the host is incorrect.

I validated the BI Server was running and listening on port 9703:

[oracle@RNMVM03 setup]$ netstat -a|grep 9703
tcp        0      0 *:9703                      *:*                         LISTEN

And I fired up Presentation Services and OC4J and successfully logged into Answers. So why couldn’t my Windows box connect?

I tried telnetting from my Windows box to the VM on port 9704 – the OC4J port. This worked, as did pinging it. So the network connectivity between the two was there. If I telnetted to port 9703 (BI Server) there was an eventual timeout.

The answer to the problem was that my Linux VM (OEL5.4) was running a firewall which I’d cleverly allowed 9704 on but not 9703. Disabling the firewall fixed the problem.

January 21, 2010

Hardening OAS

Filed under: Apache, OAS, security — rmoff @ 11:18

Oracle Application Server (OAS) is the Web and Application server typically deployed with OBIEE. There are several settings which by default may be viewed as security weaknesses. Whether realistically a target or not, it’s good practice to always be considering security and lock down your servers as much as reasonably possible. I adopt the default stance of having to find a reason to leave something less secure, rather than justify why it needs doing.

There are various tools and companies out there that will help you scan your deployments for weaknesses. In reading about this I found Nikto which runs on all platforms. In essence it takes a hostname and port and scans for known vulnerabilities in web servers (not just OAS).

Listed below are some of the simple things you can do to secure your default deployment of OAS.

Almost all of this is derived from the very excellent Securing Oracle Application Server by Caleb Sima

In the text below I refer to $OAS_HOME which may not be an actual environment variable, but is the home directory of your OAS installation.

Don’t forget to backup config files before you change them, and take backups of deleted files and directories.

After making the changes bounce OAS (opmnctl stopall; opmnctl startall).

As well as the specifics below you should always keep an eye on Oracle’s Critical Patch Updates.

Web server version and details

By default OAS will report its version in both HTTP headers and on error pages (such as those returned on a 404 Not Found which is easy to obtain by entering a non-existent URL):


Apply these two changes to $OAS_HOME/Apache/Apache/conf/httpd.conf:

  1. Search for ServerSignature and change it from On to Off
    This removes the server information from error pages
    Ref: http://httpd.apache.org/docs/2.2/mod/core.html#serversignature
  2. Add this on the next line:
    ServerTokens ProductOnly

    This removes some server version info from the HTTP header, and is the least possible data to reveal in Apache.
    Ref: http://httpd.apache.org/docs/2.2/mod/core.html#servertokens

After the changes have been made:


TRACE method

Read Apache Tips: Disable the HTTP TRACE method/ for information on how to see if HTTP TRACE is enabled. It is by default in OAS, and most security scanners will pick it up as a problem.

To disable it, add to $OAS_HOME/Apache/Apache/conf/httpd.conf:
TraceEnable Off

Default content

Most web and application servers come with default content such as example pages or “Welcome” pages, and OAS is no exception.
The reason for getting rid of this content is to give potential attackers one less thing to work with. Static content might give them information about software versions or paths. Dynamic content (JSPs etc) may be exploitable. Either way – what is to be gained from leaving it in place?

Apache default content

In $OAS_HOME/Apache/Apache:

mv htdocs/ htdocs.old
mkdir htdocs
vi htdocs/index.html
# enter:
<HTML><HEAD><TITLE>Nothing to see here</TITLE></HEAD><BODY>Nothing to see here, move along.</BODY></HTML>


rm $OAS_Home/Apache/Apache/icons/README
rm $OAS_Home/Apache/Apache/fcgi-bin/*

j2ee

cd $OAS_HOME/j2ee/home/default-web-app
rm -r WEB-INF/classes
rm -r examples/
echo "Nothing to see here" > index.html 

Pre-populated username in OAS login form

This could help an attacker as they are given a username to start trying to login as.

However, I can’t work out how to disable it. I opened a thread on OTN here:
http://forums.oracle.com/forums/thread.jspa?threadID=1010227&tstart=0

If you know, please leave a comment!

Weak ciphers / SSL version 2 supported

Disable the weak SSL ciphers & disable version 2 of the protocol

Add to httpd.conf after the TraceEnable statement from above:

SSLProtocol ALL -SSLv2
SSLCipherSuite HIGH:!SSLv2:!ADH:!aNULL:!eNULL:!NULL

Ref: http://httpd.apache.org/docs/2.0/mod/mod_ssl.html#sslciphersuite

Ref: http://adamyoung.net/Disable-SSLv2-System-Wide

Restarting OAS

When I started implementing this I used opmnctl restartproc, but found that HTTP_Server came back as status “Stop” or “Bounce”. I also got errors like: “time out while waiting for a managed process to restart”.

What I think happened was that the httpd (Apache) processes didn’t come down properly, and so couldn’t restart.

Therefore I resorted to opmnctl shutdown, then search for any remaining httpd processes (ps -ef|grep httpd) and kill any (kill -9 xxxx), and then restart OAS (opmnctl startall)

October 21, 2009

Critical Patch Update – OBIEE vuln CVE-2009-1990

Filed under: bug, obiee, security — rmoff @ 11:54

October’s Oracle Critical Patch Update Advisory has been released. There are two vulnerabilities (CVE-2009-1999, CVE-2009-1990) listed under Oracle Application Server for “Component” Business Intelligence Enterprise Edition and one (CVE-2009-3407) for “component” Portal.

  • CVE-2009-1999 is OBIEE and “Fixed in all supported versions. No patch provided in this Critical Patch Update.”.
  • CVE-2009-3407 looks like only OAS (not OBIEE), up to versions 10.1.2.3 and 10.1.4.2.
  • CVE-2009-1990 is OBIEE and is the main vuln of interest. It’s unclear if it’s just OBIEE 10.1.3.4.x, or all versions of OBIEE through to and including 10.1.3.4.1. It’s also confusing putting it on the same table as OAS especially given it has similar versioning (10.1.3.x.x).

For information about patches, see My Oracle Support Note 881382.1. This doc lists patches 8927890 and 8927886 for OBIEE 10.1.3.4.1 and 10.1.3.4.0 respectively. Since no other versions are mentioned that suggests it doesn’t affect them but that’d be a heck of an assumption to make and if I were running < 10.1.3.4.0 I'd be raising an SR to seek clarification especially given the ambiguity of the table in the Advisory doc.

The patch (8927890 for 10.1.3.4.1 / 8927886 for 10.1.3.4.0) updates libnqsmetadata and libnqsexecutionlist libraries (dll / so), so installation should be simple (and thus backout too).

Watch out for the pre-reqs on 8927890, which list the same build (10.1.3.4.0.080726.1900) as 8927886, even though it’s supposed to be for 10.1.3.4.1.
You also need to shutdown BI Scheduler (nqscheduler), even though only BI Server is named in the readme.txt.

There’s no details on the vuln itself that I can find. The READMEs for each patch simply say “This patch fixes the following bug(s)” and lists the patch number (8927886 or 8927890). On MyOracleSupport there’s no results for these bug numbers except a JDEdwards bug (!). On Metalink2 each bug turns up but is not publicly visible.

October 16, 2009

Heads up – Critical Patch Update affecting OBIEE

Filed under: bug, OAS, obiee, security — rmoff @ 09:40

The Critical Patch Update Pre-Release Announcement for October has been published. The pre-release is advance notice of the affected software prior to release of the quarterly Critical Patch Update. It is published on the Thursday prior to the patch releases (which was postponed by a week because of OOW).

It looks like if you’re running OBIEE 10.1.3.4.0 or 10.1.3.4.1 through OAS 10.1.2.3.0/10.1.3.4.0/10.1.3.5.0 then you should check back next Tuesday 20th for details.

Paraphrasing the announcement:

Security vulnerabilities addressed by this Critical Patch Update affect the following products:
[…]
• Oracle Application Server 10g Release 3 (10.1.3), versions 10.1.3.4.0, 10.1.3.5.0
• Oracle Application Server 10g Release 2 (10.1.2), version 10.1.2.3.0
[…]
• Oracle Business Intelligence Enterprise Edition, versions 10.1.3.4.0, 10.1.3.4.1
[…]
Oracle Application Server Executive Summary

This Critical Patch Update contains 3 new security fixes for the Oracle Application Server. 2 of these vulnerabilities may be remotely exploitable without authentication, i.e., may be exploited over a network without the need for a username and password. None of these fixes are applicable to client-only installations, i.e., installations that do not have an Oracle Application Server installed.
[…]
The highest CVSS base score of vulnerabilities affecting Oracle Application Server products is 4.3.

The Oracle Application Server components affected by vulnerabilities that are fixed in this Critical Patch Update are:

* Oracle Business Intelligence Enterprise Edition
[…]

More details from the Oracle Critical Patch Updates and Security Alerts page.

[update 21st October]
Details here, patch is for BI Server so presumably the application server is irrelevant

Blog at WordPress.com.