As much as I understand the sentiments here – I think we are giving ORACLE an
easy pass.
JDK 7 does not happen in isolation and by accident. There is a clear road map.
So is there a road map for OEM
And they are not from different companies And JDK 7 has been out a long time –
in fact as you know jdk 8 is the latest
For a long time ORACLE did not even care about the JDK that ships with the RDBMS
I also agree about the black box part – but unfortunately that’s not how the
corporate security apparatus work
The fact that an unsecure version of JDK is sitting on the host (at least) is
reason enough for getting security audit raised
And this will sit there for some time without any specific date when this would
remediated – because ORACLE hasn’t issued such date
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Chris Taylor
Sent: Friday, November 13, 2015 8:39 AM
To: Niall Litchfield
Cc: Tim Hall; Oracle-L Freelists
Subject: Re: WHY WHY does Oracle OEM 12c (12.1.0.5) use the following...
In the spirit of full ownership of crap I spew, Niall is exactly right. I
updated the JRE for the OEM 12c (12.1.0.5) and immediately things started
breaking. Apparently, after Java 1.7 u 85, RC4 ciphers have been removed which
Grid apparently uses so you have to update some things. *sigh*
Metalink Docs of note:
How to Install and Maintain the Java SE Installed or Used with FMW 11g/12c
Products (Doc ID 1492980.1)
MBean Error Accessing HTTP Server Configuration in FMW Control (/em) - After
Upgrading JDK (Doc ID 2049077.1)
Note
1067411.1<https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1492980.1&id=1067411.1>
How To Disable Anonymous and Weak Cipher Suites in Oracle WebLogic Server
Note
1463846.1<https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1492980.1&id=1463846.1>
JDK 7 BREAKS EM CONSOLE WHEN ATTEMPTING TO EDIT CONFIG FILES FMW 11.1.1.6 -
11.1.2.1
Note
1598061.1<https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1492980.1&id=1598061.1>
JDK 7: OWM Fails with the Error, "This function should be called while holding
treeLock"
Note
1943873.1<https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1492980.1&id=1943873.1>
Latest JDK 6 or 7: Patch 17337741 Causes Error "Too few bytes (1) received
from OPMN response" While Trying to Manage System Components Using FMW Control
Note
1450179.1<https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1492980.1&id=1450179.1>
Solaris OS: Managed Servers of a Portal, Forms, Reports, Discoverer
Installation Fail to Start with Java 7 with the Error "Unknown keyword
'useEcX963Encoding"
Note
1987534.1<https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1492980.1&id=1987534.1>
IBM JDK: When Trying To Login To EM FMW Control - Error Is Returned:
"User is not authorized to login to WebLogic Domain.
User should be part of one or more Administrative roles to be able to login"
On Thu, Nov 12, 2015 at 6:24 PM, Niall Litchfield
<niall.litchfield@xxxxxxxxx<mailto:niall.litchfield@xxxxxxxxx>> wrote:
I suspect you underestimate the engineering effort required to ensure that that
change of JVM doesn't in fact hobble anything. I mean why does anyone run apps
against Oracle 11.2 - 12.1 is just a version change right :)
On Fri, Nov 13, 2015 at 12:12 AM, Chris Taylor
<christopherdtaylor1994@xxxxxxxxx<mailto:christopherdtaylor1994@xxxxxxxxx>>
wrote:
Well, that makes me feel better at least - that I'm not alone in scratching my
head over it I mean. Seems crazy to ship out a product that contains
significant vulnerabilities when they could re-package it with a known good
java version.
Chris
On Thu, Nov 12, 2015 at 5:33 PM, Tim Hall
<tim@xxxxxxxxxxxxxxx<mailto:tim@xxxxxxxxxxxxxxx>> wrote:
Well:
1) Many (but not all) of the major security alerts around Java6 have
actually been on the client side, when running the Java plugins in
browser, so server side Java is not so much of a problem (insert
caveats here).
2) Cloud Control is not for public access, so...
3) WebLogic 11g (10.3.6) is still by far the most popular version at
this time. Oracle Fusion Apps is currently built on WebLogic 11g
10.3.6 using ADF 11.1.1.9. To my knowledge, it has not been migrated
to WebLogic 12c yet. With that in mind, it's hardly surprising other
projects have not moved forward yet.
4) The teams in Oracle each have their own deadlines and
time-to-market pressures mean they rarely use the latest products.
Testing your code base against a later release of the software takes
time that could be spent adding new features. This happens to all of
us. :)
5) Cloud Control is a shrink-wrapped application. You shouldn't be
using it for your own stuff, so why do you care what it's built with,
provided it passes your external penetration testing? I treat it like
a black box.
6) Oracle teams very rarely seem to look outside of themselves for
best practices provided by other teams. As proof I offer you the
database installations associated with eBusiness Suite, which don't
seem to follow simple best practices that I would consider DBA101.
Even if you are a good DBA, you have to check your real DBA hat in and
pick up a Oracle Apps DBA hat before doing any work on them, because
if you do things "correctly", the apps die. :)
This is not a defence of it, it's just an observation. I made a
similar comment about Java 6 when I first installed 12.1.0.5.
https://oracle-base.com/blog/2015/06/17/oracle-enterprise-manager-cloud-control-12c-release-5-12-1-0-5-my-first-two-installations/
I too get a little frustrated by this, but it is what I've come to
expect of nearly every large software vendor. Check out what's under
the hood of Microsoft BizTalk Server and you will see much the same
issues. It's cobbled together with loads of old bits of software, but
sold as a current "enterprise" solution... :)
Cheers
Tim...
--
Niall Litchfield
Oracle DBA
http://www.orawin.info
Please visit our website at
http://financialservicesinc.ubs.com/wealth/E-maildisclaimer.html
for important disclosures and information about our e-mail
policies. For your protection, please do not transmit orders
or instructions by e-mail or include account numbers, Social
Security numbers, credit card numbers, passwords, or other
personal information.
