Oracle Critical Patch Update(s)

Posting this as reminder -



January 14, 2020
Oracle Critical Patch Update for January 2020

The Critical Patch Update for January 2020 was released on January 14th, 2020. Oracle strongly recommends applying the patches as soon as possible.

If you are new to this process, please review Oracle's Security Fixing Policies and the Critical Patch Update Advisory. After reviewing these resources, if you are unable to determine if you require a software update, or how to apply it, please contact Oracle Support.

The Critical Patch Update Advisory is the starting point for relevant information. It includes the list of products affected, pointers to obtain the patches, a summary of the security vulnerabilities for each product suite, and links to other important documents. Supported products that are not listed in the "Affected Products and Components" section of the advisory do not require new patches to be applied.

Also, it is essential to review the Critical Patch Update supporting documentation referenced in the Advisory before applying patches, as this is where you can find important pertinent information.

Critical Patch Update Advisories are available at the following location:

Oracle Technology Network:

https://www.oracle.com/security-alerts/

Oracle Cloud Customers should review:

https://www.oracle.com/security-alerts/#cloud

The Critical Patch Update Advisory for January 2020 is available at the following location:

Oracle Technology Network:
https://www.oracle.com/security-alerts/cpujan2020.html


April 2020

Important information can also be found at:

https://blogs.oracle.com/oraclesecurity/

Oracle's Security Fixing Policies are available at the following location:

https://www.oracle.com/corporate/security-practices/assurance/vulnerability/security-fixing.html

The next four dates for Critical Patch Updates are:

April 14, 2020
July 14, 2020
October 20, 2020
January 19, 2021

Thank you,
Customer Support of Oracle Corporation
https://www.oracle.com/support/contact/index.html


This is useful -

Assistant: Download Reference for Oracle Database/GI Update, Revision, PSU, SPU(CPU), Bundle Patches, Patchsets and Base Releases (Doc ID 2118136.2)




Disconnected: No supported authentication methods available (server sent: publickey,gssapi-keyex,gssapi-with-mic)

I was able to login to an Oracle Cloud machine with the public IP using Putty but when connecting using MobaXterm had issues with the graphical output e.g. xclock or the Oracle Installer.

Made some changes to the sshd_config file to allow X11Forwarding for the graphical output and changed PasswordAuthentication to "no".


Using a private authentication key to access the servers so the password should not be needed.

Putty worked as expected but MobaXterm came back with

Disconnected: No supported authentication methods available (server sent: publickey,gssapi-keyex,gssapi-with-mic)

Edited the /etc/ssh/sshd_config file and c
hanged PasswordAuthentication and ChallengeResponseAuthentication to yes and restarted the sshd daemon.


#/bin/systemctl restart sshd.service

Connecting now as expected.

Thinking this needs more investigation - strange that Putty and MobaXterm behave differently.

KIling Oracle DB Connections

Had to kill an application user with thousands of connections from different app servers.

The code from the link below did the job with a slight amendment.

https://www.oracledocs.com/generating-query-to-kill-session-from-sql_id/

SELECT 'alter system kill session '
|| ''''
|| SID
|| ','
|| SERIAL#
|| ' immediate ;'
FROM v$session
WHERE sql_id = '&sql_id';

For RAC instances

SELECT 'alter system kill session '
|| ''''
|| SID
|| ','
|| SERIAL#
|| ',@'
|| inst_id
|| ''''
|| ' immediate ;'
FROM gv$session
where username='APP_USER' and machine in ('evc01','evc02','evc03')

Simply spooled the output - checked it was what we wanted - changed the .lst file to .sql and used that to kill all the sessions. Hit an ORA-00031 error when killing the session - Burleson gives more detail.

ORA-00031: session marked for kill.

Cause: The session specified in an ALTER SYSTEM KILL SESSION command cannot be killed immediately (because it is rolling back or blocked on a network operation), but it has been marked for kill. This means it will be killed as soon as possible after its current uninterruptible operation is done.

Action: No action is required for the session to be killed, but further executions of the ALTER SYSTEM KILL SESSION command on this session may cause the session to be killed sooner.