Esta es la versión corta: Google acaba de publicar una actualización de Chrome con una nota que dice: “Esta actualización incluye 1 corrección de seguridad [crítica]”.
Desafortunadamente para el usuario de Chrome, la versión larga no dice mucho más:
El canal estable se ha actualizado a 81.0.4044.113 para Windows, Mac y Linux, y se implementará en los próximos días / semanas.
[…]
Soluciones de seguridad y recompensas
Nota: El acceso a los detalles y enlaces de errores puede mantenerse restringido hasta que la mayoría de los usuarios se actualicen con el parche. También mantendremos restricciones si el error existe en una biblioteca de terceros de la que otros proyectos dependan de manera similar, pero aún no se han solucionado.
Esta actualización incluye 1 corrección de seguridad. Consulte la página de seguridad de Chrome para obtener más información.
[$ TBD] [1067851] CVE-2020-6457 crítico: error use-after-free en el reconocimiento de voz. Reportado por Leecraso y Guang Gong de Alpha Lab, Qihoo 360 el 2020-04-04
El error en sí sigue siendo un secreto, a pesar de que el núcleo de Chromium del navegador Chrome es un proyecto de código abierto. Las modificaciones de software que parchearon este agujero se harán públicas en un futuro pero, presumiblemente, que no lo sean ahora significa que tanto la naturaleza del error como la forma de explotarlo se puede deducir fácilmente de la solución.
Incluso los parches de software de código cerrado que revelan cambios solo en el nivel de código máquina a menudo son “desentrañados” tanto por investigadores como por delincuentes para descubrir qué estaba mal en primer lugar.
A menudo, saber qué comprobaciones específicas se agregaron al código del programa para detectar y evitar posibles exploits puede ahorrarle a un atacante semanas o incluso meses de búsqueda de errores.
Por ejemplo, imagina que sabes que una imagen de un tamaño extraño podría bloquear un algoritmo de procesamiento de píxeles.
Eso por sí solo sería una pista de cómo provocar un fallo, pero es posible que debas probar decenas de miles de millones de combinaciones para redescubrir el error tu mismo.
Pero ahora imagina que puedes ver claramente que el código toma precauciones especiales (verificaciones que antes no existían), como bloquear el procesamiento de imágenes donde la altura es exactamente 1.337 veces el ancho y los píxeles de las esquinas son rojos.
Es un poco como saber cuatro de los seis números de lotería antes de que comience el sorteo, lo que te da una oportunidad mucho mayor que cualquiera que juegue al azar.
Como explicamos en un artículo reciente sobre un agujero día cero de Firefox, un error use-after-free obtiene su nombre de una función común del sistema llamada free () que los programadores deben llamar para devolver bloques de memoria al sistema operativo cuando han terminado de usarlos.
Los programadores que se olvidan de llamar a free () pueden terminar acaparando mucha más memoria de la que realmente necesitan, lo que puede atascar el resto del sistema.
Pero los programadores que llaman a free () tienen que tener mucho cuidado de no seguir usando el bloque de memoria liberado por error.
De lo contrario, para cuando lleguen a depender de los datos en ese bloque de memoria, otro proceso u otra parte del mismo software puede haber comenzado a usarlo para otra cosa.
Por ejemplo, si lees un número que supuestamente te dirá el tamaño del próximo paquete de red, pero alguien ya ha sobrescrito ese número con, digamos, la cantidad total de espacio disponible en el disco, podría terminar con una respuesta como 3 mil millones cuando el número correcto no debe ser más que, digamos, 300.
De este tipo de error pueden surgir problemas peligrosos, lo que básicamente significa que el software trata los datos no confiables como si se pudieran confiar totalmente.
Como escribimos la última vez:
En algunos casos, los bugs use-after-free pueden permitir que un atacante cambie el flujo de control dentro del programa, incluyendo el desvío de la CPU para ejecutar código no fiable que el atacante acaba de introducir en la memoria desde el exterior, eludiendo así cualquiera de los controles de seguridad habituales del navegador o de los diálogos de “¿está seguro?
Este es el tipo más grave de exploit, conocido en la jerga como RCE, abreviatura de ejecución remota de código, que significa justo lo que dice: que un ladrón puede ejecutar código en su ordenador de forma remota, sin previo aviso, incluso si está al otro lado del mundo.
Suponemos, ya que este error está clasificado como crítico, que habilita RCE.
¿Qué hacer?
Curiosamente, a pesar de ser un error que es lo suficientemente crítico como para implicar que es explotable y que explotarlo podría permitir que un delincuente implante malware en su ordenador, Google informa que la nueva versión “se lanzará en los próximos días / semanas”.
Días puede estar bien, pero semanas nos parece demasiado, por lo que recomendamos pasar por el proceso de actualización lo antes posible.
Ve al menú de configuración > Información de Chrome (o Información de Chromium si usas la versión no patentada del navegador) y verifica que tienes la versión 81.0.4044.113 o posterior.
Si aún no estás parcheado, comprobar la versión debería activar automáticamente una actualización.
Por otro lado, esperábamos que hubiera una manera fácil de desactivar el reconocimiento de voz de Chrome y, por lo tanto, tal vez neutralizar este error. (¿Quién sabía que había un reconocedor de voz integrado en el navegador mismo?)
Pero no podemos encontrar ninguna manera de configurar el reconocimiento de voz, o incluso una configuración de Chromium que reconozca su existencia.
Especulamos que desactivar completamente el acceso al micrófono en Chrome podría ayudar, pero no sabemos si eso sería suficiente para evitar que el código defectuoso se active de todos modos, dado que el código defectuoso podría usarse antes de que aparezca el mensaje “permitir acceso al micrófono”.
Si sabes cómo (y, mejor aún, si sería una solución para este error), ¡infórmanos en los comentarios a continuación!
