Usando el "Last Login Time" para mejorar la seguridad de la base de datos

Es bastante común que en una base de datos Oracle tengamos la necesidad de saber si se están realizando conexiones con determinados usuarios. Esto puede ser por diferentes motivos, esquemas o usuarios creados y que nunca se han utilizado, empleados desvinculados, aplicaciones que se han migrado de base de datos pero sus esquemas originales aún permanecen, etc. Pueden existir muchas y variada razones.

Para poder detectar esto, sin necesidad de recurrir a la auditoria, desde la versión 12c Oracle comenzó a registrar el último inicio de sesión exitoso.

Esta información es almacenada en la tabla  SYS.USER $ y pueder ser consultada en la columna LAST_LOGIN de la vista DBA_USERS. Como ya mencioné, esta funcionalidad es independiente de la auditoria.

Cuando iniciamos sesión utilizando SQL*Plus, podemos ver esta información en el texto del banner.

[oracle@server01 ORADB12C][~]$ sqlplus test01

SQL*Plus: Release 12.1.0.2.0 Production on Sat Feb 13 06:31:51 2021

Copyright (c) 1982, 2014, Oracle.  All rights reserved.

Enter password:

Last Successful login time: Sat Feb 13 2021 06:31:01 -05:00

Connected to:

Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production

With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,

Advanced Analytics, Real Application Testing and Unified Auditing options

Diferencia entre "Session User" y "Current User"

En esta breve publicación voy a trata de explicar dos conceptos que en muchas oportunidades suelen confundirse (o por lo menos no quedan del todo claros). Estoy hablando de “session user” y “current user”.

En bases de datos Oracle, durante el tiempo de vida de una sesión, es muy probable que el usuario conectado utilice privilegios de diferentes usuarios. Esto sucede muy a menudo y de manera transparente (en el detrás de escena de la sesión). 

En todo momento, mientras esté viva la sesión, podemos identificar dos usuarios prinicpales: el usuario de sesión (“session user”)  y el usuario actual (“current user”). Estas dos identidades pueden referirse  al mismo usuario o pueden ser diferentes de acuardo al privilegio que se esté utilizando.

Veamos primero de que se trata cada uno de estos conceptos y posteriormente voy a usar un ejemplo para tratar de ilustrarlo.

Session user: Es el usuario con el que fue iniciada la sesión en la base de datos. Este usuario permanece sin cambios durante el tiempo de vida de la sesión. A veces se denomina también usuario de inicio de sesión. Podemos conocer cuál es, utilizando la función sys_context con el namespace USERENV(que hace referencia a la sesión actual) y el parámetro SESSION_USER: SYS_CONTEXT ('USERENV', 'SESSION_USER'). 

Si, por ejemplo, nos conectamos a la base de datos como USERS1, entonces el usuario de sesión será USERS1.

Current user: Es el usuario cuyos privilegios están actualmente activos. Este usuario puede cambiar a lo largo del tiempo de vida de la sesión. Podemos saber cuál es “current user” en determinado momento utilizando también la función sys_context con USERENV, pero en este caso con el parámetro ‘CURRENT_USER’: 

SYS_CONTEXT ('USERENV', 'CURRENT_USER').

Por ejemplo, si el usuario USER1 está ejecutando un procedimiento almacenado propiedad del usuario USER2, durante el tiempo que dure la ejecución del mismo, el usuario actual será USER2 y el usuario de sesión permanecerá sin cambios como USER1.(Cuando un usuario ejecuta un procedimiento o función, del cual no es propietario, y al cual se le han otorgado permisos  de ejecución, los privilegios del owner del procedimiento o función son activados). 

Oracle 21c: Common Mandatory Profiles

Oracle Database 21c incorpora la posibilidad de forzar restricciones en cuanto a la longitud y composición de las contraseña en las PDBs. Esto se puede realizar, creando un perfil mandatorio (“mandatory profile”) en el CDB raíz y aplicándolo luego a una, varias o todas las PDBs.

El perfil mandatorio, es un nuevo tipo de perfil genérico donde sólo pueden ser configurados los parámetros password_verify_function y password_grace_time para determinar la longitud de la contraseña. 
Para crearlo se utiliza la sentencia:

SQL> create mandatory profile ...

Este perfil agrega una verificación de longitud mínima de contraseña a los perfiles locales que están asociados con los usuarios de las PDBs por medio de una función de validación.

Definido en el contenedor raíz (CDB $ ROOT),  actúa como un perfil de usuario que está permanentemente activo. Los límites definidos en este, se aplican de manera adicional a los límites existentes del perfil que tenga asignado el usuario. Esto crea un efecto de unión ya que la función de verificación de complejidad de la contraseña del perfil mandatorio se ejecutará antes que la propia función (si es que la hubiera) del perfil asignado a la cuenta de usuario.

Esto quiere decir que la longitud de la contraseña definida en el perfil mandatorio tendrá prioridad sobre cualquier longitud de contraseña definida en otro perfil asociado al usuario.

Al poder ser creado o modificado solamente desde el CDB $ ROOT, un administrador de PDB no puede eliminar el requisito de complejidad de contraseña impuesto por el perfil mandatorio  facilitando de esta manera que los usuarios puedan establecer contraseñas más cortas e inseguras.

Perfiles para STIG y CIS en Oracle 21c

Con cada nueva versión de base de datos, Oracle mejora varios aspectos relacionados con la seguridad. En esta línea, con la versión 12.2 incorporó un nuevo perfil de usuario llamado ORA_STIG_PROFILE para cumplir con el estándar de configuración STIG (Security Technical Implementation Guide).

Este perfil aborda varios requisitos de STIG, como la necesidad de una función de complejidad de contraseña, tiempo de reutilización de las mismas, número máximo de intentos fallidos de login y algunos otros más.

La configuración de ORA_STIG_PROFILE en las versiones 12.2, 18c y 19c es la siguiente:

SQL> SELECT profile,resource_name,limit 

FROM dba_profiles 

WHERE profile='ORA_STIG_PROFILE' 

ORDER BY resource_name;

 

PROFILE                      RESOURCE_NAME                  LIMIT

---------------------------- ------------------------------ --------

ORA_STIG_PROFILE             COMPOSITE_LIMIT                DEFAULT

ORA_STIG_PROFILE             CONNECT_TIME                   DEFAULT

ORA_STIG_PROFILE             CPU_PER_CALL                   DEFAULT

ORA_STIG_PROFILE             CPU_PER_SESSION                DEFAULT

ORA_STIG_PROFILE             FAILED_LOGIN_ATTEMPTS          3

ORA_STIG_PROFILE             IDLE_TIME                      15

ORA_STIG_PROFILE             INACTIVE_ACCOUNT_TIME          35

ORA_STIG_PROFILE             LOGICAL_READS_PER_CALL         DEFAULT

ORA_STIG_PROFILE             LOGICAL_READS_PER_SESSION      DEFAULT

ORA_STIG_PROFILE             PASSWORD_GRACE_TIME            5

ORA_STIG_PROFILE             PASSWORD_LIFE_TIME             60

ORA_STIG_PROFILE             PASSWORD_LOCK_TIME             UNLIMITED

ORA_STIG_PROFILE             PASSWORD_REUSE_MAX             10

ORA_STIG_PROFILE             PASSWORD_REUSE_TIME            365

ORA_STIG_PROFILE             PASSWORD_VERIFY_FUNCTION       ORA12C_STIG_VERIFY_FUNCTION

ORA_STIG_PROFILE             PRIVATE_SGA                    DEFAULT

ORA_STIG_PROFILE             SESSIONS_PER_USER              DEFAULT

 

17 rows selected.

Oracle 21c: Novedades en la seguridad de la base de datos

Finalmente, Oracle Database 20c fué sólo un versión de "preview" y no va a existir oficialmente como release (de hecho ya no está disponible para prueba en el cloud de Oracle).

Por otro lado, los primeros dias de diciembre fue disponibilizada en Always Free Autonomous Database (solamente en las siguientes regiones: IAD, PHX, LHR, FRA) y Database Cloud Service (RAC y single-instance sobre VM; single-instance en "Bare Metal") la nueva versión Oracle Database 21c y su correspondiente documentación.

Se debe tener en cuenta que 21c es un "Innovation Release", con lo cual sólo estará soportada 2 años y medio a partir de su liberación, y no tendrá disponible soporte extendido.

En este artículo, mi colega Lisandro Fernigrini explica detalladamente las diferencias entre las versiones "Innovation Release" y "Long Term Support Release" para quien quiera comprender mejor estos conceptos.

En el post "What's new in Oracle Database 20c Security?" de febrero de este año, enumeraba algunas de las nuevas funcionalidades y cambios de comportamiento relacionados con seguridad, del (en ese momento) nuevo release 20c.

Que sucederá con ellas entonces? 

Pues, al haber sido 20c una versión de prueba, todas estas funcionalidades siguen presentes también en el nuevo release 21c.

A continuación, un breve resumen de las novedades más destacadas relacionadas con funcionalidades de seguridad para la nueva versión.

What's new in Oracle Database 20c Security?

A cloud preview of Oracle Database 20c was recently released and your documentation is also available.

Oracle Database 20c Documentation.

As usual, many changes are introduced (new features incorporated, behavior changes, deprecated and desupported Features, etc.)

Regarding to database security features, the most relevant things are:

Behavior Changes, Deprecated and Desupported Features:

It is important to take a look at these sections of the 20c documentation, to ensure that none of the security features we are using are affected.

Behavior Changes for Oracle Database 20c Upgrade Planning

• About Read-Only Oracle Homes

Deprecated Features in Oracle Database 20c

• Deprecation of Traditional Auditing
• Deprecation of Older Algorithms in DBMS_CRYPTO
• Deprecation of Enterprise User Security (EUS) User Migration Utility
• Deprecation of TLS 1.0 (Transport Layer Security

Desupported Features in Oracle Database 20c

• Desupport of DBMS_OBFUSCATION_TOOLKIT Package
• Desupport of DBMS_CRYPTO_TOOLKIT_TYPES and DBMS_CRYPTO_TOOLKIT
• Desupport of Oracle ACFS Security (Vault) and ACFS Auditing
• Desupport of ACFS Encryption on Solaris and Windows

Desupported Parameters in Oracle Database 20c

• Desupport of UNIFIED_AUDIT_SGA_QUEUE_SIZE
• Desupport of IGNORECASE Parameter for Passwords

Ya está disponible Oracle Key Vault 18.2

Ya está disponible para su descarga, instalación o actualización la versión 18.2 de Oracle Key Vault. OKV, como es denominado comúnmente, es una plataforma para la gestión de claves  de manera robusta, segura y totalmente compatible con los estándares del mercado. Permite almacenar, administrar y compartir de manera simple  “objetos de seguridad” tales como: claves de encriptación, Oracle Wallets,  Java Key Store(JKS), Java Cryptography Extension KeyStore (JCEKS) y credentialstores. Esto convierte a OKV en una excelente opción para centralizar las claves de seguridad de manera robusta en un ambiente principalmente nutrido de productos del Oracle Stack.

Desde el punto del DBA, sin lugar a dudas, es un producto que facilita muchísimo la gestión centralizada a nivel “corporativo” de las claves utilizadas por las bases de datos Oracle (también MySQL) tanto en ambientes on-premises como híbridos.  Según mi opinión, esto hace buenos aportes tanto al mundo de la administración (DBA) como al de la seguridad corporativa y gestión de riesgos.

Con la versión previa de Oracle Key Vault (18.1) se introdujo además una arquitectura de cluster “multimaster” que permite que distintos nodos geográficamente distribuidos brinden servicio, lo cual mejora notablemente la disponibilidad de las “claves”.

Con este nuevo release (18.2) se incorporan mejoras en la administración y seguridad del producto así como también una implementación más sencilla.

Dentro de estas mejoras y nuevas funcionalidades podemos encontrar:

1.) Rotación del certificado para el servidor OKV

OKV 18.2 introduce la capacidad de poder rotar los certificados del servidor OKV sin ningún tipo de “downtime” ni  intervención del lado de la base de datos, eliminando así la necesidad de actualizar los certificados de forma manual y volver a tener que enrolar  todos los “endpoints”.

Oracle CPU de Enero 2020 (Critical Patch Update)

El último CPU (Critical Patch Update) liberado el pasado martes 14 de enero, aborda 334 nuevas vulnerabilidades de seguridad en diversas familias de productos Oracle dentro de las que se incluyen: Oracle Database Server, Oracle Communications Applications, Oracle Construction and Engineering, Oracle E-Business Suite, Oracle Enterprise Manager, Oracle Financial Services Applications, Oracle Food and Beverage Aplicaciones, Oracle Fusion Middleware, Oracle GraalVM, Oracle Health Sciences Applications, Oracle Hospitality Applications, Oracle Hyperion, Oracle iLearning, Oracle Java SE, Oracle JD Edwards, Oracle MySQL, Oracle PeopleSoft, Oracle Retail Applications, Oracle Siebel CRM, Oracle Systems, Oracle Supply Chain, Oracle Utilities Applications, Oracle Virtualization.

Este CPU comprende aproximadamente un 35% de vulnerabilidades (Common Vulnerabilities and Exposures- CVEs) que no son propias de productos Oracle,  es decir,  de los 334 parches de seguridad proporcionados por este CPU, 117 son para CVEs de productos "non-Oracle", lo cual implica correcciones de seguridad para productos de terceros (por ejemplo, componentes de código abierto) que si son incluidos en las distribuciones tradicionales de productos de Oracle. En varios casos, el mismo CVE aparece varias veces en el “Critical Patch Update Advisory”, porque un componente con determinada vulnerabilidad (por ejemplo, Apache) puede estar presente en muchos productos Oracle diferentes.

El estándar CVSS v3 considera que las vulnerabilidades con un puntaje base de CVSS entre 9.0 y 10.0 tienen una calificación cualitativa de "Crítica". Las vulnerabilidades con un puntaje base de CVSS entre 7.0 y 8.9 tienen una calificación cualitativa de "Alta". Al igual que con el CPU anterior, la cantidad de CVEs que no son propias de Oracle,  representan una cantidad significativa de expuestos críticos y de alta gravedad: 27 de las 117 CVE que no son propias de productos Oracle, son por vulnerabilidades altas y críticas. Lo cual resulta significativo.

Oracle Critical Patch Update Advisory - January 2018

January 16, 2018

Oracle Critical Patch Update for January 2018

The Critical Patch Update for January 2018 was released on January 16th, 2018.

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 Critical Patch Update Advisory - October 2017

October 17, 2017

Oracle Critical Patch Update for October 2017

The Critical Patch Update for October 2017 was released on October 17th, 2017.
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:

Modificando el período de retención de archivos de auditoria en DBCS

El script /var/opt/oracle/cleandb/cleandblogs.pl  es el encargado de automatizar  tareas de archivado y depuración de archivos de diagnóstico y logs en un despliegue de DBCS, entre ellos los archivos generados por auditoria (*.aud) que dependiendo de la configuración y actividad de la base de datos pueden ser muchos. 
Este script corre semanalmente como un crontab y por defecto elimina  los archivos de auditoria (*.aud) que tienen una antiguedad mayor a 14 dias, según podemos verlo en la definición de la documentación correspondiente:
Managing the Log and Diagnostic Files on Database Cloud Service

Tal vez esta cantidad de días nos pueda resultar poca, o tal vez muy elevada.
Vamos a ver como podemos cambiar el período de retencíon de archivos de auditoría.

Como primer paso nos paramos en el directorio cleandb, aqui es donde encontramos el script de depuración y el archivo de configuración:

[oracle@server01 cleandb]$ cd /var/opt/oracle/cleandb

[oracle@server01 cleandb]$ ls -lrt
total 24
-r-xr-xr-x 1 oracle oinstall 19174 Jun  9 22:59 cleandblogs.pl
-r-xr-xr-x 1 oracle oinstall   237 Jun  9 22:59 cleandblogs.cfg

El script realiza la depuración y archivado de diferentes tipos de archivos de la base de datos, veamos el código que nos interesa a nosotros para este caso (*.aud):

[oracle@server01 cleandb]$ cat cleandblogs.pl |grep -i aud
               "AuditRetentionDB"  => 1,
           "select 'adumpDest:'||value from v\$parameter where name = 'audit_file_dest'"];
$log->logprt("Processing audit logs...\n");
PurgeLogFiles("$results{'adumpDest'}/*.aud",$CleanLogs->{AuditRetentionDB});
PurgeLogFiles("$ORACLE_HOME/rdbms/audit/*.aud",$CleanLogs->{AuditRetentionDB});

Vemos que el script trabaja con la variable/parámetro AuditRetentionDB.

En el archivo cleandblogs.cfg ,ubicado en el mismo directorio del script, encontramos la definición de la variable: 

Lock automático de cuentas con INACTIVE_ACCOUNT_TIME

En Oracle  Release 12.2 podemos usar el parámetro INACTIVE_ACCOUNT_TIME en un profile, para bloquear automáticamente una cuenta de usuario con la cual no se ha iniciado sesión en los últimos "n "días. Número especificado por el parámetro. 

1-  Por default está seteado en UNLIMITED
2-  La configuración  mínima es de 15 dias y la máxima de 24855

col RESOURCE_NAME for a43
col limit for a23
set lines 299
SQL> select RESOURCE_NAME,limit from dba_profiles where profile='DEFAULT';

RESOURCE_NAME                               LIMIT
------------------------------------------- -----------------------
COMPOSITE_LIMIT                             UNLIMITED
SESSIONS_PER_USER                           UNLIMITED
CPU_PER_SESSION                             UNLIMITED
CPU_PER_CALL                                UNLIMITED
LOGICAL_READS_PER_SESSION                   UNLIMITED
LOGICAL_READS_PER_CALL                      UNLIMITED
IDLE_TIME                                   UNLIMITED
CONNECT_TIME                                UNLIMITED
PRIVATE_SGA                                 UNLIMITED
FAILED_LOGIN_ATTEMPTS                       10
PASSWORD_LIFE_TIME                          180
PASSWORD_REUSE_TIME                         UNLIMITED
PASSWORD_REUSE_MAX                          UNLIMITED
PASSWORD_VERIFY_FUNCTION                    NULL
PASSWORD_LOCK_TIME                          1
PASSWORD_GRACE_TIME                         7
INACTIVE_ACCOUNT_TIME                       UNLIMITED ----------- > This is the resource_name introduced in oracle 12.2.

17 rows selected.

col RESOURCE_NAME for a43
col limit for a23
set lines 299
SQL> select RESOURCE_NAME,limit from dba_profiles where profile='DEFAULT';

RESOURCE_NAME                               LIMIT
------------------------------------------- -----------------------
COMPOSITE_LIMIT                             UNLIMITED
SESSIONS_PER_USER                           UNLIMITED
CPU_PER_SESSION                             UNLIMITED
CPU_PER_CALL                                UNLIMITED
LOGICAL_READS_PER_SESSION                   UNLIMITED
LOGICAL_READS_PER_CALL                      UNLIMITED
IDLE_TIME                                   UNLIMITED
CONNECT_TIME                                UNLIMITED
PRIVATE_SGA                                 UNLIMITED
FAILED_LOGIN_ATTEMPTS                       10
PASSWORD_LIFE_TIME                          180
PASSWORD_REUSE_TIME                         UNLIMITED
PASSWORD_REUSE_MAX                          UNLIMITED
PASSWORD_VERIFY_FUNCTION                    NULL
PASSWORD_LOCK_TIME                          1
PASSWORD_GRACE_TIME                         7
INACTIVE_ACCOUNT_TIME                       UNLIMITED ----------- > This is the resource_name introduced in oracle 12.2.

17 rows selected.

Oracle Critical Patch Update - July 2017

July 18, 2017

Oracle Critical Patch Update for July 2017

The Critical Patch Update for July 2017 was released on July 18th, 2017.
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.

Oracle Security Alert for CVE-2017-3629

Critical Patch Updates

Los Critical Patch Updates son colecciones de "fixes" de seguridad para distintos productos Oracle. Estos, están disponibles para clientes con contratos de soporte vigente. Son liberados el martes más próximo al día 17 de los meses de enero, abril, julio y octubre. Quedan entonces disponibles a los clientes Oracle 4 CPU por año.

El 19 de junio fué liberado el tercer CPU de este año.

Oracle Security Alert for CVE-2017-3629

How to write SQL injection proof PL/SQL (White Paper)

Muy interesante muy interesante Oracle White Paper sobre como escribir Pl/SQL a prueba de "SQL Injection"

Oracle White Paper
How to write SQL injection proof PL/SQL

ABSTRACT 
An internet search for “SQL injection” gets about 4 million hits. The topic excites interest and superstitious fear. This whitepaper dymystifies the topic and explains a straightforward approach to writing database PL/SQL programs that provably guarantees their immunity to SQL injection. Only when a PL/SQL subprogram executes SQL that it creates at run time is there a risk of SQL injection; and you’ll see that it’s easier than you might think to freeze the SQL at PL/SQL compile time. Then you’ll understand that you need the rules which prevent the risk only for the rare scenarios that do require run-time-created SQL. It turns out that these rules are simple to state and easy to follow.

http://www.oracle.com/technetwork/database/features/plsql/overview/how-to-write-injection-proof-plsql-1-129572.pdf

Parámetros de seguridad obsoletos en 12cR2

El día de ayer, el experto en seguridad de base de datos Oracle, Pete Finigan (Inglaterra), publicó en su blog un post tratando sobre la obsolececia en Oracle Database 12cR2 de dos parámetros de base la base de datos relacionados con temas de seguridad.
Se trata de: 

• O7_DICTIONARY_ACCESSIBILITY
• UTL_FILE_DIR

Como comenta Pete, estos parametros formaron parte durante años de las guias de "hardening" y auditoría de base de datos. Si bien, todavía no fueron eliminados ya se consideran obsoletos.

Aqui el link al post original:

O7_DICTIONARY_ACCESSIBILITY and UTL_FILE_DIR in Oracle 12c release 2

Usando "dbaascli database changepassword" para cambiar un password en la nube

El subcomando "database changepassword" del utilitario "dbaascli" (perteneciente al "Cloud Tooling") se utiliza para cambiar la contraseña de un usuario de la base de datos. Esta es una manera simple, sin la necesidad de hacerlo utilizando comandos SQL o alguna consola gráfica.

Para realizar esta tarea debemos ejecutar el comando con el usuario "oracle".

$ dbaascli database changepassword

Introducimos el nombre de usuario y la nueva contraseña cuando se nos solicite.

Oracle Critical Patch Update - April 2017

April 18th, 2017

Oracle Critical Patch Update for April 2017

The Critical Patch Update for April 2017 was released on April 18th, 2017. 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 Critical Patch Update - January 2017

January 17, 2017 Oracle Critical Patch Update for January 2017 The Critical Patch Update for January 2017 was released on January 17th, 2017. 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 Critical Patch Update Advisory – October 2016

Siguiendo su ritmo de publicación trimestral de actualizaciones, Oracle publica su boletín de seguridad de octubre. Contiene parches para 253 nuevas vulnerabilidades diferentes en múltiples productos pertenecientes a diferentes familias, que van desde el popular gestor de base de datos Oracle Database hasta Solaris, Java o MySQL. 

Los fallos se dan en varios componentes de múltiples productos y como es habitual la lista de productos afectados es extensa.

A continuación ofrecemos una relación de productos y el número de vulnerabilidades corregidas:
Nueve nuevas vulnerabilidades corregidas en Oracle Database Server (una de ellas explotable remotamente sin autenticación), 2 vulnerabilidades en Oracle Secure Backup (ambas explotables remotamente sin autenticación) y una nueva vulnerabilidad corregida en Oracle Big Data Graph. Afectan a los componentes: OJVM, Kernel PDB, Application Express, RDBMS Programmable Interface, RDBMS Security y RDBMS Security and SQL*Plus.