Just a short heads-up for those who might run into similar issues and having a hard time finding the root cause:
I just ran into a bug on a Windows 184.108.40.206 DB with the 190416 Bundle Patch: A newly scheduled job just wouldn’t run, and a query on DBA_SCHEDULER_JOBS revealed that other jobs (even Oracle’s own jobs) had not run in a while.
Does that headline sound fishy? Actually, Diff and Merge (WinMerge, to be exact) were my last resort in this disaster scenario. The final outcome could be told quite shortly, though this scenario serves as a good example how Murphy might hit you anytime… but first things first:
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 220.127.116.11.
The BSI announces that all versions of Oracle WebLogic-Server are affected (also including the currently actual version 18.104.22.168).
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
For quite some time I planned to write a short series about automatically deploying Oracle Servers with Ansible – particularly with the module “ansible-oracle“. My Time Thieves didn’t allow that, so today, on ODC Appreciation Day, let me give this short rave on the great contribution by Mikael Sandström to our community!
This is more a note to myself in case I’ll encounter a similar environment. But maybe it helps others – at least my search results weren’t suitable to Windows in the first place.
C:\> set ORACLE_HOME=C:\path\to\grid\home
C:\> set ORACLE_SID=+ASM1
connected to an idle instance.
Some troubles — especially those happening only sporadically — are not so easy to shoot and call for a deeper understanding of the matter. In the following real-world example this means: SQL*Net Tracing and some knowledge about the inner workings of the server’s operating system, particularly random number generation.
This case was suited well to demonstrate an approach to trouble-shoot connections to Oracle databases.
Sometimes it’s hard to find what you’re looking for in the Oracle documentation or on MOS if you don’t already know what exactly to search for. This happened to me while trying to find out how the method of changing the DB connection for the EM repository changed in 13c. So I thought my findings are worth sharing.
In earlier releases of Enterprise Manager (Grid Control or Cloud Control), connection settings were stored in a file named “emoms.properties”. While this file still existed on the EM 13.2 environment I was working on, there wasn’t any connection string in it.
After searching for quite a while (sifting a wealth of outdated documents), I found out there’s a specific emctl command to set the DB connection. This command already exists since 11g where it had to be used when the repository DB was put in a RAC. Now it seems to be the only way to change the connect string, be it RAC or single instance.