Although it’s a few days old, I’d like to point out an article by my colleague Markus Knies who had to deal with this vulnerability right on day zero:
Oracle released the quarterly critical patch updates on April 16th, 2019. Only one week later a zero-day vulnerability was identified by the KnownSec-404 security team. The vulnerability exists in Oracle Weblogic Server and has been labeled as CVE-2019-2725 and is also reported by the BSI (Bundesamt für Sicherheit in der Informationstechnik, Zero-Day-Schwachstelle in Oracle WebLogic Server, 25.04.2019).
Affected modules for this vulnerability are the wls9_async_response package with its components wls9_async and wls-wsat. With the help of these two modules it is possible to execute malicious content with elevated privileges.
Oracle reacted fast, broke the regular patch process, and launched an independent emergency patch on April 26th,2019:
Oracle reports that there is only an impact at the following versions: Oracle WebLogic Server, versions 10.3.6.0 and 184.108.40.206.
The BSI announces that all versions of Oracle WebLogic-Server are affected (also including the currently actual version 220.127.116.11).
The vulnerability CVSS score for this issue is 9.8. It is highly recommended to install this patch as soon as possible in affected systems.
Oracle – Oracle Security Alert Advisory: https://www.oracle.com/technetwork/security-advisory/alert-cve-2019-2725-5466295.html
F5L2019 – F5 Labs: Twitter-Meldung: https://mobile.twitter.com/F5Labs/status/1120822404568244224/photo/1
Pag2019 – Pierluigi Paganini: „Zero-day vulnerability in Oracle WebLogic“: https://securityaffairs.co/wordpress/84450/breaking-news/oracle-weblogic-zeroday.html
Heise – Oracle WebLogic Server via Zero-Day-Lücke aus der Ferne angreifbar (26.04.2019): https://www.heise.de/security/meldung/Oracle-WebLogic-Server-via-Zero-Day-Luecke-aus-der-Ferne-angreifbar-4408439.html
Heise – Oracle patcht kritische Lücke in WebLogic Server außer der Reihe (29.04.2019): https://www.heise.de/security/meldung/Oracle-patcht-kritische-Luecke-in-WebLogic-Server-ausser-der-Reihe-4409153.html?wt_mc=rss.security.beitrag.atom
via Zero Day vulnerability in Oracle WebLogic Servers – Oracle Patch available | The Cattle Crew Blog
Up to Oracle 11.2 it was possible to display archived SQL plans from Statspack using DBMS_XPLAN. I make use of this in some of my scripts and SQL Developer Reports since I first saw this in Christian Antognini’s Book “Troubleshooting Oracle Performance“.
But in 12c (here: 18.104.22.168 on Linux), there’s a piece missing now:
select * from table(dbms_xplan.display(
table_name => 'perfstat.stats$sql_plan',
statement_id => null,
format => 'ALL -predicate -note',
filter_preds => 'plan_hash_value = '|| &&phv
ERROR: an uncaught error in function display has happened; please contact Oracle support
Please provide also a DMP file of the used plan table perfstat.stats$sql_plan
ORA-00904: "TIMESTAMP": invalid identifier
So it looks like STATS$SQL_PLAN wasn’t synchronized to the changes in 12c’s PLAN_TABLE. Maybe because the timestamp wouldn’t make much sense there, anyway, maybe simply because Oracle forgot.
==> Quick and most certainly unsupported workaround:
ALTER TABLE perfstat.stats$sql_plan ADD timestamp INVISIBLE AS (cast(NULL AS DATE));
Another workaround could be to create a separate view with an additional dummy timestamp column an reference the view. I chose to stick with the invisible column solution so I won’t have to create new objects in the DB and change scripts to use these objects.
Hopefully, this will be solved in 12.2 – at least, I had filed an SR / Enhancement Request with Oracle Support.
First things first:
Thou shalt not explicitly set AQ_TM_PROCESSES=0 !
Unless, of course, you want to disable the Queue Manager Process (QMNC in Oracle 11.x). Which you may want to do during database upgrades to prevent Streams or Advanced Queueing from interfering with the upgrade process.
However, if you don’t reset this parameter afterwards, you might run into the following scenario the next time you do a Data Pump export or import:
Just the other day I hit the unpublished Bug 16445132: DBMS_SCHEDULER PROBLEM WITH DATABASE MIGRATION VIA EXPDP/IMPDP.
It affects Scheduler Jobs that were created to end with a corresponding Scheduler Window.
Here’s an excerpt of a Data Pump Logfile:
ORA-39083: Object type PROCOBJ failed to create with error:
ORA-27469: STOP_ON_WINDOW_EXIT is not a valid job attribute
Actually, the correct attribute name for this procedure would be “stop_on_window_CLOSE” instead of “stop_on_window_EXIT”. The latter is an attribute of the JOB_DEFINITION object type which in my eyes is inconsistently named in respect to the SET_ATTRIBUTE procedure.
The bug is fixed, but as of Nov. 2014 there is no one-off patch for version 22.214.171.124. The existing workaround is to ignore the error and recreate the job after the import .
If you run into this bug and it bugs you a lot, the other option is to ask for a patch for this issue.
Oracle’s “Security Alert Advisory for CVE-2012-3132” issued a warning about an attack vector that once again was discovered by security expert David Litchfield. The vulnerability allows to execute SQL code with SYS privileges by using object names containing quotation marks, if the attacker
- has authorized access to the database,
- has CREATE TABLE and CREATE PROCEDURE privileges and
- is allowed to execute DBMS_STATS.
A fix for this issue was published in July 2012 but there’s also Oracle’s advisory on how to cope with the threat without patching the RDBMS. This recommendation, however, has implications when such a database is recovered or cloned: