Test for CVE-2015-0204 | SSL Freak Attack

The vulnerability allows attackers to intercept HTTPS connections between vulnerable clients and servers and force them to use ‘export-grade’ cryptography, which can then be decrypted or altered. When a vulnerable browser connects to a server that supports RSA_EXPORT cipher suites, the browser can be forced to use a 512-bit RSA key. This can happen if the client is using a version of OpenSSL susceptible to CVE-2015-0204 or another library with a similar bug.

Websites that support RSA export cipher suites (e.g., TLS_RSA_EXPORT_WITH_DES40_CBC_SHA) are at risk to having HTTPS connections intercepted

How to TEST WebSite:
1. Install OPENSS (I’ve always used this
2. Open a cmd.exe and navigate to \openssl\bin\
3. Run openssl s_client -connect : -cipher EXPORT

If the website does not support RSA Export chipper suites, then your handshake will fail and you will get back to command prompt.

If the site does support RSA Export chippers, you will successfully complete the handshake and then command prompt will wait on a blank prompt

How to test clients (browser):
Open browser, go to https://cve.freakattack.com/
If this sites loads and shows something like below, this browser is vulnerable.


Apple is working on a fix.
OpenSSL has a fix, released in January ’15.

RSA silently downgrades to EXPORT_RSA [Client] (CVE-2015-0204)

Severity: Low

An OpenSSL client will accept the use of an RSA temporary key in a non-export
RSA key exchange ciphersuite. A server could present a weak temporary key
and downgrade the security of the session.

This issue affects all current OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8.

OpenSSL 1.0.1 users should upgrade to 1.0.1k.
OpenSSL 1.0.0 users should upgrade to 1.0.0p.
OpenSSL 0.9.8 users should upgrade to 0.9.8zd.

This issue was reported to OpenSSL on 22nd October 2014 by Karthikeyan
Bhargavan of the PROSECCO team at INRIA. The fix was developed by Stephen
Henson of the OpenSSL core team.

Reference 1
Reference 2
Reference 3
Reference 4


When using DBMS_STATS to gather statistics, we need a method to choose which objects to gather statistics for. This is done by the parameter “OPTIONS”. The possible values for this parameter are


Of the above, GATHER AUTO & GATHER STALE confuse many – let’s see what’s the main difference between the two.

GATHER STALE: Oracle gathers statistics on stale objects as determined by looking at the *_tab_modifications views. The estimate percent & degree have to be provided by the user.

GATHER AUTO : Oracle decides which objects to gather fresh statistics for and also decides how to get them. Oracle determines the estimate percent to be used. The parallelism used is based on the init.ora setting. This also used *_TAB_MODIFICATIONS to decide on the eligible candidates.


In 12c, Oracle has done away with most of these and provides only GATHER and GATHER AUTO




Check if HyperThreading is Enabled on Your Windows Server

It turns out that our datacentre guys had HyperThreading not turned on in our Oracle Database Server. We’re talking about ~30% improvement in performance with it turned on. Here’s a quick way to check if HyperThreading is enabled in Windows.

It uses the fact that when hyperthreading is enabled, the number of logical processors will be higher than number of cores.

Copy the below code and save it as ht_check.vbs

To run, open a command prompt, cd to the location you have the script saved (or use full path) and call
cscript ht_check.vbs

strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set Plist = objWMIService.ExecQuery _
("Select * from Win32_Processor")
For Each prox in Plist
IF prox.NumberOfLogicalProcessors > prox.NumberOfCores THEN
Wscript.Echo "Num of Logical Procs:" + CStr(prox.NumberOfLogicalProcessors)
Wscript.Echo "Num of Cores:" + CStr(prox.NumberOfCores)
Wscript.Echo "Num of Logical Procs:" + CStr(prox.NumberOfLogicalProcessors)
Wscript.Echo "Num of Cores:" + CStr(prox.NumberOfCores)

Collection Status : Disabled by Upload Manager & EMD upload error: uploadXMLFiles Skipped:: OMS version not checked yet

I was getting “Collection Status : Disabled by Upload Manager” on one of my EM targets. Now, I prefer to have monitoring and DBA tasks done the old school way, with scripts and all. But we have EM deployed for all targets and this is something that I had to fix.

I started by doing a “emclt upload” and see what it gave. I got the error “EMD upload error: uploadXMLFiles Skipped:: OMS version not checked yet.” . So I went back to MOS to see if  there was any help there. Note 1086343.1 is a good reference.

Upon looking at the emagent log and trace files, I saw that there were connection problems to the OMS repository. Turns out that the targets.xml file (which has details on the various monitored components on any host) was messed up.

To create a new targets.xml file, I took backups and ran the following:

emctl stop agent  --> stop the agent
agentca -d        --> force a discovery of the targets on the host

This took a while, but created a new targets.xml which has all details. I Edited the file to have only the databases that I wanted EM to monitor and removed the rest. The targets.xml is by default created without the password for the connect user (DBSNMP). So  add these two lines for each target (DB). make sure that encrypted is set to FALSE. On the next agent startup, these will be automatically encrypted (username & pwd)

<Property NAME="password" VALUE="password" ENCRYPTED="FALSE"/>

Once this was done, I started the agent up using emctl start agent and all was good.

GParted in OEL6

wget http://dl.fedoraproject.org/pub/epel/6/x86_64/gparted-0.6.0-1.el6.x86_64.rpm


rpm -Uvh gparted-0.6.0-1.el6.x86_64.rpm