20130404ActualizacionSeguridad

From PostgreSQL wiki
Jump to navigationJump to search

PostgreSQL: Actualización de Seguridad del 4 de Abril de 2013

FYI (traducción al español no oficial del anuncio y FAQ en inglés)

Preguntas Frecuentes

La actualización incluye las siguientes versiones:

  • v9.2.4
  • v9.1.9
  • v9.0.13
  • v8.4.17

Estas preguntas se enfocan en la vulnerabilidad CVE-2013-1899.

¿Hay alguna brecha de seguridad (exploit) conocida y liberada para esta vulnerabilidad?

No hay exploits conocidos a la fecha de esta liberación.

¿Quién es particularmente vulnerable por este incidente?

Cualquier sistema que permita acceso irrestricto al puerto de red de PostgreSQL (generalmente 5432), como usuarios corriéndolo en una nube pública, especialmente vulnerable. Son menos vulnerables aquellos servidores solamente accesible en redes internas protegidas, los que tengan un cortafuegos efectivo o algún otra restricción de red.

Esta es una buena regla general para la seguridad de Bases de Datos: no permitir acceso al puerto del servidor desde redes no confiadas salvo que sea absolutamente necesario. Esto es verdad, o incluso más verdadero, para otros sistemas de bases de datos como lo es para PostgreSQL.

¿Cual es la naturaleza de la vulnerabilidad?

La vulnerabilidad permite usar un parámetro de línea de comandos para la conección de PostgreSQL (previsto para el modo de recuperación de usuario único) mientras PostgreSQL esta ejecutándose en modo normal multi-usuario. Esto puede se usado para dañar al servidor.

¿Cual es la potencial brecha de seguridad abierta por esta vulnerabilidad?

  1. Denegación de Servicio Persistente: un atacante no autenticado puede usar esta vulnerabilidad para causar que un mensaje de error sea agregado a un archivo específico en el directorio de datos del servidor. Los archivos corrompidos de esta manera pueden causar que el servidor caiga y se reuse a reiniciar. El servidor puede ser arreglado ya sea editando el archivo y eliminado el texto basura, o recuperándolo de una copia de seguridad.
  2. Escalamiento de Privilegios de Configuración: en el caso de que un atacante tenga un login legítimo al servidor de base de datos, y el servidor esta configurado para que el usuario y nombre de base de datos sea idéntico (por ej. usuario `web`, base de datos `web`), entonces esta vulnerabilidad puede ser usada para establecer temporalmente una variable de configuración con el privilegio de super usuario.
  3. Ejecución Arbitraria de Código: si el atacante reúne todas las condiciones del punto 2, y tiene la habilidad de guardar archivos (aún en el directorio temporal), entonces puede usar esta vulnerabilidad para cargar y ejecutar código arbitrario en C. SELinux prevendrá este tipo específico de brecha de seguridad.

¿Que versiones principales de PostgreSQL son afectadas?

Versiones 9.0, 9.1 y 9.2.

Los usuarios de las versiones 8.4 no son afectados. Los usuarios de las versiones 8.3 o anteriores tampoco son afectados por este incidente, pero son vulnerables a otras vulnerabilidades no parcheadas, dado que esas versiones han agotado su vida útil.

¿Como se pueden proteger los usuarios?

  • Descargando la actualización y actualizando todos sus servidores lo antes posible.
  • Asegurnadose que PostgreSQL no está abierto a conexiones de redes no confiables.
  • Auditando los usuarios de sus bases de datos para estar seguros de que se requiere las credenciales de acceso apropiadas, y que solo existen usuarios legítimos y activos.
  • Usando marcos de trabajo de seguridad avanzados, como SELinux con la extensión PostgreSQL's SEPostgres, también ayuda a eliminar la exposición a un daño potencial por vulnerabilidades de seguridad de PostgreSQL.

¿Cuando fue descubierta la vulnerabilidad?

Esta vulnerabilidad fue reportada al Grupo de Desarrolladores Global de PostgreSQL el 12 de Marzo de 2013.

¿Quién descubrió la vulnerabilidad?

Mitsumasa Kondo y Kyotaro Horiguchi de NTT Open Source Software Center lo descubrieron mientras hacían una auditoria de seguridad. NTT (Nippon Telegraph and Telephone Corporation) es un contribuidor de larga data a PostgreSQL.

¿Como fue reportada la vulnerabilidad?

Kondo-san y Horiguchi-san enviaron un email a security@postgresql.org

¿Como se organiza el Proyecto PostgreSQL?

PostgreSQL Global Development Group (PGDG) es una organización de voluntarios. Tenemos un equipo núcleo de seis personas, un numeró mayor de Contribuidores Principales y varias listas de correo que conforman la parte centralizada de la comunidad. Ver el listado de contribuidores en: http://www.postgresql.org/community/contributors/

¿Que tan seguido PostgreSQL encuentra una vulnerabilidad de seguridad?

Encontramos de cero a siete incidentes menores por año. Este es el primer incidente de magnitud desde 2006: el "backslash escape encoding issue", que también afectó a MySQL y a otros sistemas de bases de datos.

¿Como se introdujo la vulnerabildiad?

Fue creada como un efecto colateral de un esfuerzo de refactoring para hacer que el establecimiento de conexiones sea más rápido, y el código más mantenieble.

¿Quien descubre las vulnerabilidades en PostgreSQL?

Somos afortunados en tener un grupo grande de ingenieros en seguridad que prueban a PostgreSQL regularmente y responsablemente reportan los incidentes de seguridad para que puedan ser solucionados. Esto incluye:

  • Empleados de QA en las compañías colaboradoras como NTT Open Source, EnterpriseDB y 2ndQuadrant
  • Investigadores de Seguridad en la Agencia Japonesa Federal de Seguridad
  • Investigadores de Seguridad en empresas de seguridad, como Secunia
  • Coverity’s Scan Project
  • y nuestro gran grupo de usuarios que participan en la comunidad, quienes reportan los errores.

¿Que se incluye además en esta actualización?

Esta liberación también actualiza otros cuatro incidentes de seguridad menores que están detallados en la página de seguridad y en el comunicado de liberación. También incluye un número de correcciones, principalmente para dos potenciales incidentes de corrupción de datos con replicación binaria.

Anuncio Completo

El Grupo de Desarrollo Global de PostgreSQL ha liberado una actualización de seguridad para todas las versiones actuales del sistema de bases de datos PostgreSQL, incluyendo versiones 9.2.4, 9.1.9, 9.0.13, y 8.4.17. Esta actualización corrige una vulnerabilidad de seguridad de alta exposición en la versión 9.0 y posteriores. Se recomienda aplicar la actualización "inmediatamente" a todos los usuarios de las versiones afectadas.

Un incidente mayor de seguridad ha sido corregido en esta liberación, CVE-2013-1899 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1899), donde una solicitud de conexión conteniendo un nombre de base de datos que empiece con "-" maliciosamente armado podía dañar archivos dentro del directorio de datos del servidor. Cualquiera con acceso al puerto en el que escucha el servidor PostgreSQL podía iniciar esta solicitud. El incidente fue descubierto por Mitsumasa Kondo y Kyotaro Horiguchi del NTT Open Source Software Center.

Dos incidentes menores también se incluyen en esta liberación: CVE-2013-1900 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1900), donde los números aleatorios generados por las funciones de contrib/pgcrypto podrían fácilmente ser adivinados por otros usuarios; y CVE-2013-1901 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1901), el cual incorrectamente permite a un usuario sin privilegios ejecutar órdenes que pudieran interferir con una copia de seguridad en progreso. Por último, esta liberación corrige dos incidentes de seguridad con el instalador gráfico para Linux y Mac OS X: "pasaje inseguro de contraseñas de superusuario a un script", CVE-2013-1903 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1903) y "nombres de archivos predecibles en /tmp" CVE-2013-1902 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1902). Marko Kreen, Noah Misch y Stefan Kaltenbrunner reportaron dichos incidentes, respectivamente.

Les agradecemos a dichos desarrolladores los esfuerzos para hacer a PostgreSQL más seguro.

También esta liberación corrige varios errores en el manejo de indices GiST indexes. Luego de instalar la actualización, es recomendable hacer un REINDEX sobre los índices GiST que cumplan con una o más de las condiciones descritas a continuación.

Esta actualización también contiene correcciones para muchos otros temas menores, descubiertos y corregidos por la comunidad PostgreSQL en los últimos dos meses, incluyendo:

  • Corregir índices GiST a que no usen comparaciones geométricas "fuzzy" para columnas box, polygon, circle, y point
  • Corregir problemas en contrib/btree_gist para índices GiST en columnas text, bytea, bit, y numeric
  • Corregir problemas en el código de división de páginas para índices GIST multi-columna
  • Corregir filtración en buffer en WAL replay causando errores de "incorrect local pin count"
  • Asegurar recuperación ante caídas antes de entrar en la recuperación de archivamiento durante un cierre no limpio cuando recovery.conf está presente
  • Evitar eliminar archivos WAL no-archivados-aún durante una recuperación de caída
  • Corregir condición de carrera en DELETE RETURNING
  • Corregir caída posible del planificador luego de agregar columnas a una vista dependiente de otra vista
  • Eliminar las filtraciones de memoria en PL/Perl's spi_prepare()
  • Corregir pg_dumpall para manejar nombres de bases de datos que contengan "="
  • Evitar caídas en pg_dump cuando una cadena de conección incorrecta es proporcinada
  • Ignorar índices inválidos en pg_dump and pg_upgrade
  • inculir solo el subdirectorio de la versión actual cuando se hace una copia de seguridad de un tablespace con pg_basebackup
  • Agregar un chequeo de versión en pg_basebackup y pg_receivexlog
  • Corregir contrib/dblink para manejar ajustes inconsistentes de DateStyle o IntervalStyle de manera segura
  • Corregir contrib/pg_trgm's similarity() para devolver 0 para ajustes trigram-less strings
  • Habilitar construir PostgreSQL con Microsoft Visual Studio 2012
  • Actualizar los archivos de zonas horarias por cambios en leyes DST en Chile, Haiti, Marruecos, Paraguay, y algunas áreas en Rusia

Como es habitual, la actualización solo requiere la instalación de los paquetes y un reinicio del sistema de base de datos. No es necesario hacer un volcado/restauración o usar pg_upgrade para esta actualización. Los usuarios que han evitado varias actualizaciones pueden requerir realizar pasos adicionales luego de la actualización. Ver las Release Notes para los detalles

Enlaces: