[h]OpenSSL 1.0.2.a :
Nueva versión de OpenSSL que corrige varias brechas desveladas [/h]
https://www.wifi-libre.com/img/members/3/socket1.jpg
OpenSSL es un proyecto comunitario y de código abierto como lo indica “Open” en su nombre.
SSL significa “Security Socket Layer”.
Es decir que OpenSSL actua como una “capa de seguridad” : integra varias funciones criptográficas y soluciones para elevar nuestro nivel de seguridad.
Un ejemplo muy concreto : Cuando un navegador web establece una conexión https (más segura que http) va a pillar librerías y cositas proporcionadas por openSSL.
Sabiendo que 90% de los servidores usan linux se pueden imaginar la importancia que tienen openSSL si consideramos el nivel de seguridad global de la red.
¿A lo mejor se recuerden de Hearthbleed? https://www.wifi-libre.com/img/members/3/Socket2.jpg
Se habló muchísimo de este bug de OpenSSL; parecía ser el apocalipsis … ( generalmente se usa https-openSSL para las transacciones de pago ).
Las 12 brechas develadas estos días son menos llamativas ya que de las dos consideradas como “criticas”; la que va de “robo de datos” afecta solo vejas versiones y la otra (que afecta la penúltima versión) permite hacer ataques de denegación de servicio. Molesto pero no tanto como transacciones bancarias no encriptadas… Aquí las tenéis :
[code]OpenSSL Security Advisory [19 Mar 2015]
OpenSSL 1.0.2 ClientHello sigalgs DoS (CVE-2015-0291)
Severity: High
If a client connects to an OpenSSL 1.0.2 server and renegotiates with an
invalid signature algorithms extension a NULL pointer dereference will occur.
This can be exploited in a DoS attack against the server.
This issue affects OpenSSL version: 1.0.2
OpenSSL 1.0.2 users should upgrade to 1.0.2a.
This issue was was reported to OpenSSL on 26th February 2015 by David Ramos
of Stanford University. The fix was developed by Stephen Henson and Matt
Caswell of the OpenSSL development team.
Reclassified: RSA silently downgrades to EXPORT_RSA [Client] (CVE-2015-0204)
Severity: High
This security issue was previously announced by the OpenSSL project and
classified as “low” severity. This severity rating has now been changed to
“high”.
This was classified low because it was originally thought that server RSA
export ciphersuite support was rare: a client was only vulnerable to a MITM
attack against a server which supports an RSA export ciphersuite. Recent
studies have shown that RSA export ciphersuites support is far more common.
This issue affects OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8.
OpenSSL 1.0.1 users should upgrade to 1.0.1k.
OpenSSL 1.0.0 users should upgrade to 1.0.0p.
OpenSSL 0.9.8 users should upgrade to 0.9.8zd.
This issue was reported to OpenSSL on 22nd October 2014 by Karthikeyan
Bhargavan of the PROSECCO team at INRIA. The fix was developed by Stephen
Henson of the OpenSSL core team. It was previously announced in the OpenSSL
security advisory on 8th January 2015.
Multiblock corrupted pointer (CVE-2015-0290)
Severity: Moderate
OpenSSL 1.0.2 introduced the “multiblock” performance improvement. This feature
only applies on 64 bit x86 architecture platforms that support AES NI
instructions. A defect in the implementation of “multiblock” can cause OpenSSL’s
internal write buffer to become incorrectly set to NULL when using non-blocking
IO. Typically, when the user application is using a socket BIO for writing, this
will only result in a failed connection. However if some other BIO is used then
it is likely that a segmentation fault will be triggered, thus enabling a
potential DoS attack.
This issue affects OpenSSL version: 1.0.2
OpenSSL 1.0.2 users should upgrade to 1.0.2a.
This issue was reported to OpenSSL on 13th February 2015 by Daniel Danner and
Rainer Mueller. The fix was developed by Matt Caswell of the OpenSSL development
team.
Segmentation fault in DTLSv1_listen (CVE-2015-0207)
Severity: Moderate
The DTLSv1_listen function is intended to be stateless and processes the initial
ClientHello from many peers. It is common for user code to loop over the call to
DTLSv1_listen until a valid ClientHello is received with an associated cookie. A
defect in the implementation of DTLSv1_listen means that state is preserved in
the SSL object from one invocation to the next that can lead to a segmentation
fault. Errors processing the initial ClientHello can trigger this scenario. An
example of such an error could be that a DTLS1.0 only client is attempting to
connect to a DTLS1.2 only server.
This issue affects OpenSSL version: 1.0.2
OpenSSL 1.0.2 DTLS users should upgrade to 1.0.2a.
This issue was reported to OpenSSL on 27th January 2015 by Per Allansson. The
fix was developed by Matt Caswell of the OpenSSL development team.
Segmentation fault in ASN1_TYPE_cmp (CVE-2015-0286)
Severity: Moderate
The function ASN1_TYPE_cmp will crash with an invalid read if an attempt is
made to compare ASN.1 boolean types. Since ASN1_TYPE_cmp is used to check
certificate signature algorithm consistency this can be used to crash any
certificate verification operation and exploited in a DoS attack. Any
application which performs certificate verification is vulnerable including
OpenSSL clients and servers which enable client authentication.
This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0 and 0.9.8.
OpenSSL 1.0.2 users should upgrade to 1.0.2a
OpenSSL 1.0.1 users should upgrade to 1.0.1m.
OpenSSL 1.0.0 users should upgrade to 1.0.0r.
OpenSSL 0.9.8 users should upgrade to 0.9.8zf.
This issue was discovered and fixed by Stephen Henson of the OpenSSL
development team.
Segmentation fault for invalid PSS parameters (CVE-2015-0208)
Severity: Moderate
The signature verification routines will crash with a NULL pointer
dereference if presented with an ASN.1 signature using the RSA PSS
algorithm and invalid parameters. Since these routines are used to verify
certificate signature algorithms this can be used to crash any
certificate verification operation and exploited in a DoS attack. Any
application which performs certificate verification is vulnerable including
OpenSSL clients and servers which enable client authentication.
This issue affects OpenSSL version: 1.0.2
OpenSSL 1.0.2 users should upgrade to 1.0.2a
This issue was was reported to OpenSSL on 31st January 2015 by Brian Carpenter
and a fix developed by Stephen Henson of the OpenSSL development team.
ASN.1 structure reuse memory corruption (CVE-2015-0287)
Severity: Moderate
Reusing a structure in ASN.1 parsing may allow an attacker to cause
memory corruption via an invalid write. Such reuse is and has been
strongly discouraged and is believed to be rare.
Applications that parse structures containing CHOICE or ANY DEFINED BY
components may be affected. Certificate parsing (d2i_X509 and related
functions) are however not affected. OpenSSL clients and servers are
not affected.
This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0
and 0.9.8.
OpenSSL 1.0.2 users should upgrade to 1.0.2a
OpenSSL 1.0.1 users should upgrade to 1.0.1m.
OpenSSL 1.0.0 users should upgrade to 1.0.0r.
OpenSSL 0.9.8 users should upgrade to 0.9.8zf.
This issue was discovered by Emilia Käsper and a fix developed by
Stephen Henson of the OpenSSL development team.
PKCS7 NULL pointer dereferences (CVE-2015-0289)
Severity: Moderate
The PKCS#7 parsing code does not handle missing outer ContentInfo correctly.
An attacker can craft malformed ASN.1-encoded PKCS#7 blobs with
missing content and trigger a NULL pointer dereference on parsing.
Applications that verify PKCS#7 signatures, decrypt PKCS#7 data or
otherwise parse PKCS#7 structures from untrusted sources are
affected. OpenSSL clients and servers are not affected.
This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0
and 0.9.8.
OpenSSL 1.0.2 users should upgrade to 1.0.2a
OpenSSL 1.0.1 users should upgrade to 1.0.1m.
OpenSSL 1.0.0 users should upgrade to 1.0.0r.
OpenSSL 0.9.8 users should upgrade to 0.9.8zf.
This issue was reported to OpenSSL on February 16th 2015 by Michal
Zalewski (Google) and a fix developed by Emilia Käsper of the OpenSSL
development team.
Base64 decode (CVE-2015-0292)
Severity: Moderate
A vulnerability existed in previous versions of OpenSSL related to the
processing of base64 encoded data. Any code path that reads base64 data from an
untrusted source could be affected (such as the PEM processing routines).
Maliciously crafted base 64 data could trigger a segmenation fault or memory
corruption. This was addressed in previous versions of OpenSSL but has not been
included in any security advisory until now.
This issue affects OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8.
OpenSSL 1.0.1 users should upgrade to 1.0.1h.
OpenSSL 1.0.0 users should upgrade to 1.0.0m.
OpenSSL 0.9.8 users should upgrade to 0.9.8za.
The fix for this issue can be identified by commits d0666f289a (1.0.1),
84fe686173 (1.0.0) and 9febee0272 (0.9.8). This issue was originally reported by
Robert Dugal and subsequently by David Ramos.
DoS via reachable assert in SSLv2 servers (CVE-2015-0293)
Severity: Moderate
A malicious client can trigger an OPENSSL_assert (i.e., an abort) in
servers that both support SSLv2 and enable export cipher suites by sending
a specially crafted SSLv2 CLIENT-MASTER-KEY message.
This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0
and 0.9.8.
OpenSSL 1.0.2 users should upgrade to 1.0.2a
OpenSSL 1.0.1 users should upgrade to 1.0.1m.
OpenSSL 1.0.0 users should upgrade to 1.0.0r.
OpenSSL 0.9.8 users should upgrade to 0.9.8zf.
This issue was discovered by Sean Burford (Google) and Emilia Käsper
(OpenSSL development team) in March 2015 and the fix was developed by
Emilia Käsper.
Empty CKE with client auth and DHE (CVE-2015-1787)
Severity: Moderate
If client auth is used then a server can seg fault in the event of a DHE
ciphersuite being selected and a zero length ClientKeyExchange message being
sent by the client. This could be exploited in a DoS attack.
This issue affects OpenSSL version: 1.0.2
OpenSSL 1.0.2 users should upgrade to 1.0.2a.
This issue was discovered and the fix was developed by Matt Caswell of the
OpenSSL development team.
Handshake with unseeded PRNG (CVE-2015-0285)
Severity: Low
Under certain conditions an OpenSSL 1.0.2 client can complete a handshake with
an unseeded PRNG. The conditions are:
- The client is on a platform where the PRNG has not been seeded automatically,
and the user has not seeded manually - A protocol specific client method version has been used (i.e. not
SSL_client_methodv23) - A ciphersuite is used that does not require additional random data from the
PRNG beyond the initial ClientHello client random (e.g. PSK-RC4-SHA).
If the handshake succeeds then the client random that has been used will have
been generated from a PRNG with insufficient entropy and therefore the output
may be predictable.
For example using the following command with an unseeded openssl will succeed on
an unpatched platform:
openssl s_client -psk 1a2b3c4d -tls1_2 -cipher PSK-RC4-SHA
This issue affects OpenSSL version: 1.0.2
OpenSSL 1.0.2 users should upgrade to 1.0.2a.
This issue was discovered and the fix was developed by Matt Caswell of the
OpenSSL development team.
Use After Free following d2i_ECPrivatekey error (CVE-2015-0209)
Severity: Low
A malformed EC private key file consumed via the d2i_ECPrivateKey function could
cause a use after free condition. This, in turn, could cause a double
free in several private key parsing functions (such as d2i_PrivateKey
or EVP_PKCS82PKEY) and could lead to a DoS attack or memory corruption
for applications that receive EC private keys from untrusted
sources. This scenario is considered rare.
This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0 and 0.9.8.
OpenSSL 1.0.2 users should upgrade to 1.0.2a
OpenSSL 1.0.1 users should upgrade to 1.0.1m.
OpenSSL 1.0.0 users should upgrade to 1.0.0r.
OpenSSL 0.9.8 users should upgrade to 0.9.8zf.
This issue was discovered by the BoringSSL project and fixed in their commit
517073cd4b. The OpenSSL fix was developed by Matt Caswell of the OpenSSL
development team.
X509_to_X509_REQ NULL pointer deref (CVE-2015-0288)
Severity: Low
The function X509_to_X509_REQ will crash with a NULL pointer dereference if
the certificate key is invalid. This function is rarely used in practice.
This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0
and 0.9.8.
OpenSSL 1.0.2 users should upgrade to 1.0.2a
OpenSSL 1.0.1 users should upgrade to 1.0.1m.
OpenSSL 1.0.0 users should upgrade to 1.0.0r.
OpenSSL 0.9.8 users should upgrade to 0.9.8zf.
This issue was discovered by Brian Carpenter and a fix developed by Stephen
Henson of the OpenSSL development team.
Note
As per our previous announcements and our Release Strategy
(https://www.openssl.org/about/releasestrat.html), support for OpenSSL versions
1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these
releases will be provided after that date. Users of these releases are advised
to upgrade.
References
URL for this Security Advisory:
https://www.openssl.org/news/secadv_20150319.txt
Note: the online version of the advisory may be updated with additional
details over time.
For details of OpenSSL severity classifications please see:
https://www.openssl.org/about/secpolicy.html
[/code]
Me ha llamado la atención una , no por su gravedad, sino porque es parecida a pixie dust (cf . ). Es esta :
[quote]Handshake with unseeded PRNG (CVE-2015-0285)
Severity: Low
Under certain conditions an OpenSSL 1.0.2 client **can complete a handshake with
an unseeded PRNG. **The conditions are:
- The client is on a platform where the PRNG has not been seeded automatically,
and the user has not seeded manually - A protocol specific client method version has been used (i.e. not
SSL_client_methodv23) - A ciphersuite is used that does not require additional random data from the
PRNG beyond the initial ClientHello client random (e.g. PSK-RC4-SHA).
If the handshake succeeds then the client random that has been used will have
been generated from a PRNG with insufficient entropy and therefore the output
may be predictable.
For example using the following command with an unseeded openssl will succeed on
an unpatched platform:
openssl s_client -psk 1a2b3c4d -tls1_2 -cipher PSK-RC4-SHA
This issue affects OpenSSL version: 1.0.2
OpenSSL 1.0.2 users should upgrade to 1.0.2a.
This issue was discovered and the fix was developed by Matt Caswell of the
OpenSSL development team.
[/quote]
Como con nuestro querido “polvo de hada” (pixie dust cf: “Pixie Dust” ataque de fuerza bruta offline para generar el PIN valido ) lo que falla aquí es (en ciertos escenarios) el generador pseudo-aleatorio de números.
El protocolo es seguro en si; bajo la condición de que se respecten los " niveles de entropía requeridos". Dicho de otra forma, si se emplea una llave secreta para cifrar mensajes comunicaciones; la llave tiene que ser… segura. 
Para hacer un paralelo; si usamos como llave WPA 12345678 no hemos respectado los “niveles de entropía” (generalmente se aconseja algo como un mínimo de 12 caracteres mezclando letras maj/min números y símbolos) : Nuestra " passphrase " es susceptible de brute force (en esta caso incluso manual)
En el caso pixie dust sabemos que Ralink ha usado como llave secreta “0” (semilla 0 ) para generar la parte “secreta” que debería hacer imposible el brute force del M3 WPS
En el caso expuesto se trata exactamente del mismo tipo de fallo
El caso es que en algunas plataformas, si el usuario no inicia una semilla manualmente, la plataforma no lo hace automáticamente.
Así que se va a usar “0”…
Y ya no se necesita hacer un brute force de la semilla para hacer el brute force de los hash ( y mala suerte, algunos son reversibles)
Con pikie dust tenemos (SE1 | PKE | PKR | PK-1). Sabemos PKR, PKE; podemos adivinar PK-1 (los 10 000 primeras mitades).
SE-1 debería asegurar la seguridad siendo la llave “secreta” pero el fabricante ralink usa 0 en lugar de un generador pseudo-aleatroio como dios manda.
Con el falló openssl tenemos algo como ( PSK-RC4-SHA) donde nuestra Pre-Shared Key pasa por dos funciones de hash reversibles ya que que no necesitan laves externas y todo reposa en el nivel de seguridad de la semilla inicial empleada para formar nuestra PSK.
En este caso es también al nivel de la generación de la semilla que reside el faló
El método " pixie dust " es un buen modo para abordar posibles brechas de seguridad 
Lo que da bastante a pensar es si nos fijamos en las funciones ()random (las que se encargan de hacer semillas seguras) que se usan hoy en día en unos productos y protocolos; podemos encontrar funciones de 2002 dónde por ejemplo, el autor dice a la epoca que “es una mierda” a nivel de seguridad ( si soy grosero es para ser fiel al texto original )
[quote]#if defined(CYGIMP_LIBC_RAND_SIMPLEST)
158
159 // This algorithm sucks in the lower bits
160
161 *seed = (*seed * 1103515245) + 12345; // permutate seed
162
163 retval = (int)( *seed & RAND_MAX );
164
165 #elif defined(CYGIMP_LIBC_RAND_SIMPLE1)
166
167 // The above algorithm sucks in the lower bits, so we shave them off
168 // and repeat a couple of times to make it up
169
170 unsigned int s=*seed;
171 unsigned int uret;
172
173 s = (s * 1103515245) + 12345; // permutate seed
174 // Only use top 11 bits
175 uret = s & 0xffe00000;
176
177 s = (s * 1103515245) + 12345; // permutate seed
178 // Only use top 14 bits
179 uret += (s & 0xfffc0000) >> 11;
180
181 s = (s * 1103515245) + 12345; // permutate seed
182 // Only use top 7 bits
183 uret += (s & 0xfe000000) >> (11+14);
184 [/quote]
:lol:
La elección de esta función no es anodina sobre todo después de hablar de pixie dust… ups.
El equipo de openSSL libró antes de la publicación de las brechas una versión nueva y segura (respecto a los fallos desvelados)
Una simple actualización de nuestro sistema bastará para tener la nueva versión de OpenSSL (si no esta instalada ya automáticamente).
sudo apt-get update && sudo apt-get upgrade && sudo rebootOpenSSL esta ahora mismo bajo un audit lanzado por la linux fundation para mejorarlo
Su nivel de seguridad es obviamente un punto crucial en la mente de los de linux que lanzaron un plan ( dotado de varios millones de dolares) para auditar y mejorar algunas herramientas de código libre que son hoy en día esenciales en muchos contextos.
OpenSSL hace parte- ¡Como no! - de ellas.
Buen domingo 
[list=*]
]Publicación oficial de las brechas (full disclosure) : [19 Mar 2015] /]
]Anexo : [How To Patch and Protect OpenSSL Vulnerability # CVE-2015-0291 CVE-2015-0204]](http://www.cyberciti.biz/faq/howto-openssl-security-update-cve20150291-cve20150204-cve20150290-cve20150207-cve20150286/)/]
]Anexo : OpenSSL Advisory: No New Heartbleed But Admins Will Be Busy/]
[/list]