20140220ActualizacionSeguridad

= Actualización de Seguridad Consolidada del 2 de Febrero de 2014 =
FYI (traducción al español de 20140220securityrelease)
La actualización 2014-02-20 contiene correcciones para múltiples incidencias de seguridad. La mayoría son "Clase C", lo que significa que requieren previo inicio de sesión válido para el escalamiento de privilegios. Algunos también requieren condiciones adicionales en la base de datos para concretarse y poder ser explotados. Una corrección rompe la compatibilidad hacia atrás en una forma que cumple con nuestra documentación pero no con el comportamiento anterior.
Los siguientes resúmenes fueron provistos por Noah Misch y Tom Lane. 
== Vulnerabilidad durante "make check" ==
CVE-2014-0067 PostgreSQL: Vulnerability during "make check"
Esta incidencia no está corregido en esta liberación.
Estamos publicándolo por el interés de transparencia, por tanto los administradores de bases de datos y encargados de seguridad tomarán las medidas necesarias para asegurar sus servidores.
=== Explicación ===
El equipo de seguridad del Grupo Global de Desarrolladores de PostgreSQL
ha descubierto una vulnerabilidad en los programas que orquestan los
suites de pruebas de PostgreSQL que validan la funcionalidad de los 
binarios de PostgreSQL.
Mientras la suite de prueba esta en ejecución, un usuario con acceso 
interactivo al sistema puede secuestrar la cuenta en el sistema operativo 
del usuario corriendo la suite. Solo están en riesgo usuarios que corren 
"make check" en un sistema que comparte con usuarios no confiables. 
Un conjunto futuro de actualizaciones de seguridad corregirá esta 
vulnerabilidad, aunque no será necesario reinstalar despliegues existentes.
Mientras tanto, los usuarios son advertidos a ejecutar los suites de prueba 
solo en sistemas no compartidos o bajo cuentas de usuario del sistema 
operativo dedicadas a la tarea de ejecutar las suites de prueba.
Esta vulnerabilidad surge desde el usi de "initdb" por parte de los 
programas de prueba para crear un cluster de bases de datos PostgreSQL
permitiendo autenticación local "trust".
Flujos de trabajo similares desarrollados por usuarios haciendo la misma 
tarea exhiben la misma vulnerabilidad.
Recomendamos estudiar el uso automatizado de initdb en su propio software.
Si un procedimiento en cuestión puede ejecutarse en un sistema compartido
con usuarios no confiables, siga las mismas precauciones alrededor de los
mismos como los suites de prueba de PostgreSQL. La correción para 
PostgreSQL en sí será establecer un patrón seguro para automatizar initdb,
que usted puede adoptar luego.
En plataformas simil-Unix el atacante necesita poder alcanzar el archivo
socket del servidor, por lo que el riesgo depende en que lugar la 
plataforma pone el archivo de socket y si hay o no protecciones por 
permisos en el sistema de archivo implementadas.
En Windows, el servidor abre un socket TCP accesible localmente, por lo 
que no hay posibilidad de morigerar el riesgo mediante permisos del 
sistema de archivos.
Para hacer que esta situación sea más segura, se espera que los cambios 
requeridos sean algo invasivos y puedan romper los flujos de prueba 
desarrollados por usuarios.
Por lo tanto, el proyecto PostgreSQL no proveerá en realidad ninguna 
corrección este 20 de Febrero, y solo anunciando que hay un problema y
recomendado a los usuarios que no usen "make check" en equipos compartidos
con usuarios no confiables. Los cambios necesarios a la instalación de 
pruebas de regresión serán debatidos públicamente y puede esperarse que 
sean incorporados en futuras liberaciones.
El proyecto PostgreSQL agradece a Noah Misch por reportar este problema.
== SET ROLE bypasses lack of ADMIN OPTION ==
CVE-2014-0060 PostgreSQL: SET ROLE bypasses lack of ADMIN OPTION
This change will break backwards compatibility for users who were expecting the prior, broken behavior. The new behavior is in compliance with the documentation.
=== Explanation ===
Enforce ADMIN OPTION restrictions.
Granting a role without ADMIN OPTION is supposed to prevent the grantee
from adding or removing members from the granted role. Issuing SET ROLE
before the GRANT bypassed that, because the role itself had an implicit
right to add or remove members. This issue was fixed by recognizing that
implicit right only when the session user matches the current role.
Additionally, do not recognize it during a security-restricted operation
or during execution of a SECURITY DEFINER function. The restriction on
SECURITY DEFINER is not security-critical. However, it seems best for a
user testing his or her own SECURITY DEFINER function to see the same behavior
others will see. Affects all supported versions back to 8.4.
The SQL standards do not conflate roles and users as PostgreSQL does;
only SQL roles have members, and only SQL users initiate sessions. An
application using PostgreSQL users and roles as SQL users and roles will
never attempt to grant membership in the role that is the session user,
so the implicit right to add or remove members will never arise.
The security impact was mostly that a role member could revoke access
from others, contrary to the wishes of the role member's grantor. Unapproved
role member additions are less notable, because the member can still largely
achieve that by creating a view or a SECURITY DEFINER function.
The PostgreSQL project thanks Noah Misch and Jonas Sundman for reporting
this problem.
== Language validators are accessible for everyone ==
CVE-2014-0061 PostgreSQL: Privilege escalation via explicit calls to validator functions
=== Explanation ===
PostgreSQL procedural languages (PLs) normally provide a "validator"
function that performs creation-time checking of syntax etc. for
functions written in that language. These validator functions can
be called directly from SQL, too, which is intended to allow post-facto
checking of existing function definitions. However, unexpected and
possibly insecure results could be obtained by feeding the text of a
function defined in one language to the validator for another language.
Moreover, in many languages the validator might perform some limited amount
of code execution, opening the possibility of an attacker executing
code without permission. The security impact is thus that an authenticated
database user might be able to escalate his or her privileges.
The fix will cause validator functions to throw an error when used
against a function defined in another language, or against a function
the current user doesn't have permissions to call.
While the PostgreSQL project will fix the validator functions in PLs
distributed with PostgreSQL, the same two-line fix will be needed in
validator functions of PLs developed externally. There are many
such extensions and we cannot be certain that all of their developers
will respond promptly.
The PostgreSQL project thanks Andres Freund for reporting this problem.
== Race condition in CREATE INDEX allows for privilege escalation ==
CVE-2014-0062 PostgreSQL: Race condition in CREATE INDEX allows for privilege escalation
=== Description ===
CREATE INDEX, and some ALTER TABLE statements, did multiple
independent lookups of the table the index is
supposed to be created on. Concurrent creation or deletion of another
table of the same name (but in a different schema) might cause some of
these lookups to find one table and some the other table. This allows
effects such as creating an index on a table one doesn't own, thus
exposing data to the calling user that should not be able to access.
This vulnerability exists in all affected versions, but is more easily exploited in 9.2 and 9.3.
The PostgreSQL project thanks Andres Freund for reporting this problem.
== Potential Buffer Overruns in Datetime Input/Output ==
* CVE-2014-0063 PostgreSQL: Potential buffer overruns in datetime input/output
=== Descriptions ===
Many functions use the MAXDATELEN constant to size a buffer for parsing
or displaying a datetime value. However, the buffer was much too small
for the longest possible interval output and slightly too small for certain valid
timestamp inputs, particularly input with a long timezone name.
Inputs that were too long would be rejected needlessly, while outputs
that were too long would result in stack corruption, which could crash
the server and could be exploitable for arbitrary code execution.
The PostgreSQL project thanks Daniel Schüssler for reporting this problem.
== Buffer overflow in path_in() ==
* CVE-2014-0064 PostgreSQL: Potential buffer overruns due to integer overflow in size calculations
=== Description ===
Predict integer overflow to avoid buffer overruns.
Several functions, mostly type input functions, calculated an allocation
size such that the calculation wrapped to a small positive value when
arguments implied a sufficiently-large requirement. Writes past the end
of the inadvertent small allocation followed shortly thereafter.
Coverity Scan identified the path_in() vulnerability; code inspection led to
the rest. In passing, add check_stack_depth() to prevent stack overflow
in related functions.
Affects all supported versions back to 8.4. The non-comment hstore
changes touch code that did not exist in 8.4, so that part stops at 9.0.
== Potential Buffer Overruns of Fixed-Size Buffers ==
* CVE-2014-0065 PostgreSQL: Potential buffer overruns of fixed-size buffers
=== Explanation ===
Coverity Scan identified a number of places in which it could not prove that a
string being copied into a fixed-size buffer would fit. We believe that
most, perhaps all of these, are in fact safe or are copying data that is
coming from a trusted source so that any overrun is not really a
security issue. Nonetheless it seems prudent to forestall any risk by
using strlcpy() and similar functions.
The PostgreSQL project thanks Peter Eisentraut and Jozef Mlich for reporting
this problem.
== Potential null pointer dereference crash when crypt(3) returns NULL ==
CVE-2014-0066 PostgreSQL: Potential null pointer dereference crash when crypt(3) returns NULL
=== Explanation ===
The chkpass extension uses the standard crypt() library function, which
is defined to return NULL on failure, but it was not checking for NULL
before using the result. The main practical case in which this could be
an issue is if libc is configured to refuse to execute unapproved
hashing algorithms ("FIPS mode").
The PostgreSQL project thanks Honza Horak for reporting this problem.