Issue with ciphers after patching OJVM

Some functionality uses the embedded JDK in the database. In this case the dev team implemented sftp functionality in java using jcraft jsch, this allows to do sftp in the database. 

The ciphers that we use require to have the Java Cryptographic Extensions to be enabled in the database home.

After successfully applying OJVM RELEASE UPDATE: 12.2.0.1.191015 (3013362, the sftp transfer stopped working on all systems except one.

with errors like this 

BEGIN
*
ERROR at line 1:
ORA-20000: Java Error: com.jcraft.jsch.JSchException: Algorithm negotiation fail
at com.jcraft.jsch.Session.receive_kexinit(Session.java)
at com.jcraft.jsch.Session.connect(Session.java:320)
at com.jcraft.jsch.Session.connect(Session.java:183)
at com.xxx.util.SFTP.(SFTP:73)
at com.xxx.util.SFTP.connect(SFTP:118)
 
 
 
First checks with tcpdump and wireshark  going to the remote node of the cluster showed the same, only lower ciphers where known on the client side (in our case the DB is client to the remote host) 

A debug version of the test_sftp program showed us following 

 
 
 BEGIN
   dbms_java.set_output(0);
   test_sftp('host','user','PASSWORD!');

END;


/2345
INFO: Connecting to host port 22
INFO: Connection established
INFO: Remote version string: SSH-2.0-OpenSSH_7.4
INFO: Local version string: SSH-2.0-JSCH-0.1.53
INFO: CheckCiphers: aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,arcfour,arcfour128,arcfour256 INFO: aes256-ctr is not available.
INFO: aes192-ctr is not available.
INFO: aes128-ctr is not available.
INFO: aes256-cbc is not available.
INFO: aes192-cbc is not available.
INFO: aes128-cbc is not available.
INFO: 3des-ctr is not available.
INFO: CheckKexes: diffie-hellman-group14-sha1,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521 INFO: diffie-hellman-group14-sha1 is not available.
INFO: ecdh-sha2-nistp256 is not available.
INFO: ecdh-sha2-nistp384 is not available.
INFO: ecdh-sha2-nistp521 is not available.
INFO: CheckSignatures: ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
INFO: ecdsa-sha2-nistp256 is not available.
INFO: ecdsa-sha2-nistp384 is not available.
INFO: ecdsa-sha2-nistp521 is not available.
INFO: SSH_MSG_KEXINIT sent
INFO: SSH_MSG_KEXINIT received
INFO: kex: server: ecdh-sha2-nistp521,diffie-hellman-group14-sha1
INFO: kex: server: ssh-rsa,rsa-sha2-512,rsa-sha2-256
INFO: kex: server: aes256-gcm@openssh.com,aes256-ctr,aes256-cbc
INFO: kex: server: aes256-gcm@openssh.com,aes256-ctr,aes256-cbc
INFO: kex: server: hmac-sha2-512,hmac-sha2-256,hmac-sha1
INFO: kex: server: hmac-sha2-512,hmac-sha2-256,hmac-sha1
INFO: kex: server: none,zlib@openssh.com
INFO: kex: server: none,zlib@openssh.com
INFO: kex: server:
INFO: kex: server:
INFO: kex: client: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman- group1-sha1
INFO: kex: client: ssh-rsa,ssh-dss
INFO: kex: client: 3des-cbc,blowfish-cbc
INFO: kex: client: 3des-cbc,blowfish-cbc
INFO: kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
INFO: kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
INFO: kex: client: none
INFO: kex: client: none
INFO: kex: client:
INFO: kex: client:
INFO: Disconnecting from host port 22 

Very Strange using the procedure explained in following mos note 

OJVM Using JDK 1.8 Is Missing Cipher Suites like TLS_ECDHE_% (Doc ID 2678418.1)
The ciphers supported are following 

SQL> set serveroutput on;
SQL> exec dbms_java.set_output(10000);
PL/SQL procedure successfully completed.
SQL> select getciphers from dual;


SQL> select getciphers from dual;
And there In both cases (working and non working db) we get following output

GETCIPHERS
———-
         0
Supported Cipher Suites:
1. TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
2. TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
3. TLS_RSA_WITH_AES_256_CBC_SHA
4. TLS_DHE_RSA_WITH_AES_256_CBC_SHA
5. TLS_DHE_DSS_WITH_AES_256_CBC_SHA
6. TLS_RSA_WITH_AES_128_CBC_SHA256
7. TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
8. TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
9. TLS_RSA_WITH_AES_128_CBC_SHA
10. TLS_DHE_RSA_WITH_AES_128_CBC_SHA
11. TLS_DHE_DSS_WITH_AES_128_CBC_SHA
12. TLS_RSA_WITH_AES_256_GCM_SHA384
13. TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
14. TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
15. TLS_RSA_WITH_AES_128_GCM_SHA256
16. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
17. TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
18. TLS_EMPTY_RENEGOTIATION_INFO_SCSV

  

After drilling deeper and copying the non working  db to our sandbox environment as well as copying the home from the working db, doing some crosstesting (running none with existing home on sandbox, switching none database to working home  ) and checking all parameters in all possible configuration files ( server and client side sqlnet.ora, ssh_config files …) we came to the conclusion that the issue must be in the db.

After opening an SR with Orace this was confirmed.BTW Kudo’s to the MOS engineer I had my solution in an hour not bad for a SEV2.


 To make it working again following needs to be done 

sqlplus / as sysdba
 alter session set container=NON_WORKING_PDB;
 alter session set "_ORACLE_SCRIPT"=true;
--
note down following values
 column name format a20
 column value format a40
 select name,value from v$parameter where upper(name) in ('JAVA_JIT_ENABLED','JOB_QUEUE_PROCESSES');
NAME                 VALUE
-------------------- ----------------------------------------
java_jit_enabled     TRUE
job_queue_processes  1000
 -- Start of File Create_Java.sql
 spool Create_Java.log
 set echo on
 Alter system set JAVA_JIT_ENABLED=FALSE scope=both;
 alter system set "_system_trig_enabled" = false scope=memory;
 alter system set JOB_QUEUE_PROCESSES=0;
 create or replace java system
 /
 @?/rdbms/admin/utlrp.sql
 set echo off
 spool off
 exit
Afterwards check with the check procedure if sftp work again 
 BEGIN
   dbms_java.set_output(0);
   test_sftp('marx5130','biods','PASSWORD!');

END;

Put back the JAVA_JIT_ENABLED and JOB_QUEUE_PROCESSES to initial values
On By phil

Leave a Reply

Related Post