El Grupo Global de Desarrollo de PostgreSQL ha lanzado una actualización para todas las versiones soportadas de nuestro sistema de base de datos, incluyendo la 17.1, 16.5, 15.9, 14.14, 13.17, y 12.21. Con esta versión se corrigen de forma definitiva 4 vulnerabilidades de seguridad y 35 errores notificados en los últimos meses.

Para consultar la lista completa de los cambios realizados, revisen las notas de la versión.

Notificación de EOL para PostgreSQL 12 

Esta es la versión final de PostgreSQL 12. PostgreSQL 12 ha llegado al final de su vida útil y dejará de recibir correcciones de seguridad y errores. Si están utilizando PostgreSQL 12 en un entorno de producción, les sugerimos hacer planes para actualizar a una versión más reciente y soportada de PostgreSQL. Para más información, consulten nuestra política de versiones.

Problemas de seguridad

CVE-2024-10976: Seguridad de registros a un nivel inferior de PostgreSQL, por ejemplo en el caso de subconsultas, ignora los cambios de ID de usuario

Puntuación base CVSS v3.1: 4.2

Versiones soportadas vulnerables: 12 – 17.

El seguimiento incompleto en PostgreSQL de tablas con seguridad de registros permite que una consulta reutilizada visualice o modifique registros distintos de los previstos. Las CVE-2023-2455 y CVE-2016-2193 han solucionado la mayor parte de las interacciones entre la seguridad de registros y los cambios de ID de usuario. Sin embargo, omitían los casos en los que una subconsulta, una consulta WITH, una vista que invoca funciones de seguridad o una función en lenguaje SQL hacían referencia a una tabla con política de seguridad de registros. Las consecuencias son las mismas que las de las dos CVE anteriores. Es decir, llevan a la aplicación de políticas potencialmente incorrectas en los casos en los que se utilizan políticas específicas de rol y una consulta determinada se planifica bajo un rol y luego se ejecuta bajo otros roles. Este escenario puede ocurrir bajo funciones de definidor de seguridad o cuando un usuario y una consulta comunes tras una planificación inicial son reutilizados en múltiples ROLES SET.

La aplicación de una política incorrecta puede permitir a un usuario realizar lecturas y modificaciones no permitidas. Este problema sólo afecta a las bases de datos que han utilizado CREATE POLICY para definir una política de seguridad de registros. Un atacante debe adaptar un ataque al patrón de reutilización del plan de consulta de una aplicación específica, a los cambios de ID de usuario y a las políticas de seguridad de registros específicas de cada rol. Están afectadas las versiones anteriores a PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17 y 12.21.

El proyecto PostgreSQL agradece a Wolfgang Walther por reportar este problema.

CVE-2024-10977: La libpq de PostgreSQL retiene un mensaje de error de man-in-the-middle

Puntuación base CVSS v3.1: 3.1

Versiones soportadas vulnerables: 12 – 17.

El uso por parte del cliente de un mensaje de error del servidor en PostgreSQL permite a un servidor no confiable con configuración SSL o GSS vigente proporcionar bytes arbitrarios no NUL a la aplicación libpq. Por ejemplo, un atacante man-in-the-middle podría enviar un mensaje de error extenso que un usuario humano o un usuario screen-scraper de psql confunda con resultados de consulta válidos. Probablemente este problema no afecta a los clientes en los que la interfaz de usuario indica sin ambigüedad el límite entre un mensaje de error y otro texto. Las versiones afectadas son las anteriores a PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17 y 12.21.

El proyecto PostgreSQL agradece a Jacob Champion por reportar este problema.

CVE-2024-10978: SET ROLE, SET SESSION AUTHORIZATION de PostgreSQL restablecen el ID de usuario incorrecto

Puntuación base CVSS v3.1: 4.2

Versiones soportadas vulnerables: 12 – 17.

La asignación incorrecta de privilegios en PostgreSQL permite a un usuario de una aplicación con menos privilegios ver o modificar registros diferentes de los previstos. Para realizar un ataque es necesario que la aplicación utilice SET ROLE, SET SESSION AUTHORIZATION o una función equivalente. El problema surge cuando la consulta de una aplicación utiliza parámetros del atacante o transmite los resultados de la consulta al atacante. Si esa consulta reacciona a current_setting('role') o al ID de usuario actual, puede modificar o devolver datos como si la sesión no hubiera utilizado SET ROLE o SET SESSION AUTHORIZATION. El atacante no controla qué ID de usuario incorrecto se aplica. El texto de consulta de fuentes menos privilegiadas no supone un problema en este caso, porque SET ROLE y SET SESSION AUTHORIZATION no son sandboxes para consultas no verificadas. Las versiones afectadas son las anteriores a PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17 y 12.21.

El proyecto PostgreSQL agradece a Tom Lane por reportar este problema.

CVE-2024-10979: Cambios en variables de entorno PL/Perl en PostgreSQL ejecutan código arbitrario

Puntuación base CVSS v3.1: 8.8

Versiones soportadas vulnerables: 12 – 17.

El control incorrecto de las variables de entorno PL/Perl en PostgreSQL permite a un usuario de base de datos sin privilegios cambiar variables de entorno de procesos sensibles (por ejemplo, PATH). Esto a menudo es suficiente para permitir la ejecución de código arbitrario, incluso si el atacante no tiene privilegios como usuario del sistema operativo del servidor de base de datos. Las versiones afectadas son las anteriores a PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17 y 12.21.

El proyecto PostgreSQL agradece a Coby Abrams por reportar este problema.

Corrección de errores y mejoras

Esta actualización corrige más de 35 errores reportados en los últimos meses. Aunque los problemas que se enumeran a continuación afectan a PostgreSQL 17, es posible que algunos de ellos afecten también a otras versiones de PostgreSQL.

• Corrección al adjuntar o separar particiones de tabla con restricciones de clave foránea. Tras la actualización, los usuarios afectados por este problema deberán realizar algunos pasos de forma manual para completar la corrección. Consulten la sección «Actualización» y las notas de la versión para obtener más información.
• Corrección al utilizar libc como proveedor de intercalación predeterminado cuando LC_CTYPE es C y LC_COLLATE es una configuración regional diferente. Esto podía dar lugar a resultados de consulta incorrectos. Si una base de datos utiliza esta configuración, es necesario reindexar los índices afectados tras actualizar a esta versión. Este problema sólo afectaba a la versión 17.0.
• Se han realizado varias correcciones en el planificador de consultas, incluida la denegación de la unión de particiones (partitionwise join) si las intercalaciones de las particiones no coinciden.
• Corrección de posibles respuestas erróneas o errores del planificador de wrong varnullingrels para acciones MERGE ... WHEN NOT MATCHED BY SOURCE.
• Corrección de la validación de COPY FORCE_NOT_NULL y FORCE_NULL.
• Corrección de la caída del servidor cuando una llamada a json_objectagg() contiene una función volátil.
• Asegura que exista una dependencia registrada entre una tabla particionada y un método de acceso no incorporado especificado en CREATE TABLE ... USING. Esta corrección evita problemas únicamente en las tablas particionadas creadas tras esta actualización.
• Corrección de una condición de carrera al confirmar una transacción serializable.
• Corrección de una condición de carrera en COMMIT PREPARED que podía requerir la eliminación manual de archivos tras un bloqueo y recuperación.
• Corrección para que la vista pg_cursors evite errores al excluir cursores que no están completamente configurados.
• Reducción del consumo de memoria en la descodificación lógica.
• Corrección para evitar que las funciones estables reciban valores de registro obsoletos al ser invocadas desde la lista de argumentos de una sentencia CALL y la misma se encuentra dentro de un bloque PL/pgSQL EXCEPTION.
• Corrección de fallos JIT en sistemas ARM (aarch64).
• psql \watch ahora considera los valores menores de 1 ms como 0 (sin espera entre ejecuciones).
• Corrección del fallo al utilizar las credenciales de un usuario de replicación en el archivo de contraseñas (pgpass)
• pg_combinebackup ahora arroja un error si un archivo de respaldo incremental está presente en un directorio que debería contener un respaldo completo.
• Corrección para evitar la reindexación de tablas e índices temporales en vacuumdb y en reindexdb paralelo.

Esta versión también actualiza los archivos de datos de zonas horarias a la versión tzdata 2024b. Esta versión de tzdata cambia los antiguos nombres de zonas compatibles con System-V para duplicar las zonas geográficas correspondientes; por ejemplo, PST8PDT es ahora un alias de America/Los_Angeles. La principal consecuencia observable es que, en el caso de los timestamps anteriores a la introducción de husos horarios normalizados, se considera que la zona representa la hora solar media local para la ubicación mencionada. Por ejemplo, en PST8PDT, la entrada timestamptz como 1801-01-01 00:00 se habría representado anteriormente como 1801-01-01 00:00:00-08, pero ahora se representa como 1801-01-01 00:00:00-07:52:58.

También se han introducido correcciones históricas en México, Mongolia y Portugal. En particular, Asia/Choibalsan es ahora un alias de Asia/Ulaanbaatar en lugar de ser una zona separada, básicamente porque se descubrió que las diferencias entre esas zonas se basaban en datos poco fiables. 

Actualización

Todas las actualizaciones de PostgreSQL son acumulativas. Al igual que en otras actualizaciones menores, para instalar esta actualización no es necesario realizar un volcado y volver a cargar la base de datos o usar pg_upgrade. Es suficiente con detener PostgreSQL y actualizar los binarios.

Si se dispone de una tabla particionada con restricciones de clave foránea en la que se han ejecutado los comandos ATTACH PARTITION/DETACH PARTITION, será necesario tomar medidas adicionales tras la actualización. Es posible solucionarlo ejecutando un ALTER TABLE ... DROP CONSTRAINT en la tabla independiente para cada restricción defectuosa y, a continuación, volver a añadir la restricción. Si no es posible volver a añadir la restricción, deberá restablecerse manualmente la coherencia entre las tablas de referencia y de referencia y, a continuación, volver a añadir la restricción.

Esta consulta puede utilizarse para identificar las restricciones no válidas y construir los comandos necesarios para recrearlas:

SELECT conrelid::pg_catalog.regclass AS "constrained table", conname AS constraint, confrelid::pg_catalog.regclass AS "references", pg_catalog.format('ALTER TABLE %s DROP CONSTRAINT %I;', conrelid::pg_catalog.regclass, conname) AS "drop", pg_catalog.format('ALTER TABLE %s ADD CONSTRAINT %I %s;', conrelid::pg_catalog.regclass, conname, pg_catalog.pg_get_constraintdef(oid)) AS "add" FROM pg_catalog.pg_constraint c WHERE contype = 'f' AND conparentid = 0 AND (SELECT count(*) FROM pg_catalog.pg_constraint c2 WHERE c2.conparentid = c.oid) <> (SELECT count(*) FROM pg_catalog.pg_inherits i WHERE (i.inhparent = c.conrelid OR i.inhparent = c.confrelid) AND EXISTS (SELECT 1 FROM pg_catalog.pg_partitioned_table WHERE partrelid = i.inhparent));

Dado que es posible que uno o más de los pasos de ADD CONSTRAINT fallen, deberá guardarse la salida de la consulta en un archivo y luego intentar realizar cada paso.

Adicionalmente, si se está ejecutando PostgreSQL 17.0 y usando libc como proveedor de intercalación por defecto, y se ha establecido LC_CTYPE como C mientras que LC_COLLATE es una configuración regional diferente, se necesitará reconstruir los índices basados en texto. Es posible hacerlo con el comando REINDEX INDEX CONCURRENTLY.

Si anteriormente se omitieron una o más actualizaciones, podría ser necesario seguir algunos pasos posteriores a la actualización. Para más detalles consulten las notas de las versiones anteriores.

Para más detalles, véanse las notas de la versión.

Enlaces

• Descargas
• Notas de la versión
• Seguridad
• Política de versiones
• Sigan @postgresql en Twitter
• Donaciones

Si desean proponer alguna corrección o hacer sugerencias en relación con este anuncio de lanzamiento, envíenlas a la lista de correo pública pgsql-www@lists.postgresql.org.