Apenas tres días después de la anterior actualización de Chrome, que parcheaba 24 agujeros de seguridad, los programadores de Google anunciaron el lanzamiento de Chrome 105.0.5195.102, en el que el último de los cuatro números salta a 52 en Mac y Linux y a 54 en Windows.
Las notas de la versión confirman, en el estilo recortado y frustrante de informe de errores que Google parece haber tomado prestado de Apple:
CVE-2022-3075: Validación de datos insuficiente en Mojo.
Reportado por Anonymous el 2022-08-30
[…]
Google es consciente de los informes [sic] de que existe un exploit para CVE-2022-3075 que está siendo utilizado.
Microsoft también ha sacado una actualización, llevando su navegador, que está basado en Chromium, a Edge 105.0.1343.27.
Siguiendo el estilo superbreve de Google, Microsfoft se limitó a escribir que:
Esta actualización [Edge 105.0.1343.27] contiene una corrección para CVE-2022-3075, que ha sido reportada por el equipo de Chromium con un exploit que está siendo utilizado
Como siempre, nuestra traducción de los agujeros de seguridad escritos de esta manera no comprometida es: “Los delincuentes o los vendedores de software espía encontraron esta vulnerabilidad antes que nosotros, han descubierto cómo explotarla y ya lo están haciendo”.
¿EoP o RCE?
Nos encantaría poder determinar, dado que el fallo está relacionado con el manejo incorrecto de los datos de entrada, si este fallo conduce a un resultado de seguridad preocupante como EoP, abreviatura de elevación de privilegios, o si se puede abusar de él para obtener un resultado más desastroso como un RCE en toda regla, abreviatura de ejecución remota de código.
EoP normalmente significa que los delincuentes necesitan un punto de apoyo de malware para empezar, por lo que los errores de EoP normalmente no pueden ser explotados para romper las defensas.
Aun así, es vital parchearlos, porque un delincuente que se cuele en tu ordenador bajo la cobertura de un usuario limitado como GUEST a menudo traerá consigo un exploit EoP para “promocionarse” y así tener poderes de root o sysadmin, con el objetivo de convertir lo que podría haber sido un riesgo moderado en un solo ordenador en un compromiso total de toda tu red.
Los exploits RCE, por otro lado, se utilizan comúnmente para conseguir una cabeza de playa dentro de una red para iniciar un ataque, o para saltar repetidamente de un ordenador a otro una vez dentro, o ambas cosas.
Una vez más, la brevedad del informe de Google hace que, aunque el informe del fallo sea Alto y no Crítico, supongamos que estamos hablando de un RCE, y por lo tanto asumir que un atacante decidido podría utilizar este fallo para implantar malware desde cero.
Mojo e IPC
Mojo, por si te lo estás preguntando, es una biblioteca de código de Google para lo que se conoce como IPC, abreviatura de comunicación entre procesos.
Hoy en día, por razones de seguridad, los navegadores no suelen ejecutarse como un único proceso monolítico del sistema operativo.
En términos generales, un proceso puede constar de varios hilos, que son esencialmente “subprocesos” dentro del proceso principal, mediante los cuales un solo programa puede seguir haciendo tranquilamente dos cosas al mismo tiempo, como imprimir un documento mientras se desplaza por él, o llevar a cabo una revisión ortográfica en segundo plano.
Dividir una aplicación de un solo proceso en hilos es más conveniente (con esto queremos decir que “es mucho más rápido y fácil, pero mucho menos seguro”) que dividirla en procesos separados, porque todos los hilos dentro de un proceso tienen acceso al mismo trozo de memoria.
Esto significa que los hilos pueden interactuar y compartir datos más fácilmente, porque pueden simplemente sumergirse directamente en el mismo grupo de datos común, incluyendo la comprobación de los ajustes de configuración actuales, el intercambio de direcciones de memoria, el intercambio de manejadores de archivos, la reutilización de imágenes en caché directamente desde la RAM, y mucho más.
Por otro lado, compartir un gran espacio de memoria significa que un fallo en una parte del programa, como el hilo que está ocupado en la renderización y visualización de tu primera pestaña del navegador, podría pisotear o afectar al código que está ocupado con otras cosas, como los hilos que manejan el resto de las pestañas que tienes abiertas.
Como resultado, los navegadores modernos generalmente se dividen en numerosos procesos separados, por ejemplo, cada pestaña maneja un proceso independiente, evitando así que una pestaña problemática pueda filtrar trivialmente datos como cookies y tokens de acceso de otras pestañas relacionadas con sitios web completamente diferentes.
Comunicación entre procesos
Esto significa que se necesita una forma segura y fiable de transferir datos entre los distintos procesos del navegador.
En lugar que la pestaña A y la pestaña B simplemente consulten un bloque común de memoria M en el hilo principal del navegador, los procesos independientes de la pestaña A y la pestaña B necesitan recibir sus propias copias de los datos que necesitarán.
Y ahí es donde se necesita un sistema de comunicación interprocesos, o IPC.
Cualquier proceso que baraje datos entre sí a través de IPC necesita ponerse de acuerdo sobre cómo construir esos datos correctamente para su envío, y cómo deconstruirlos de forma segura en el otro extremo.
El término de la jerga para esto es serialización y deserialización, porque estás tomando trozos de datos, posiblemente arrancados del contenido ya almacenado en numerosas áreas diferentes de la memoria, y convirtiendo esos trozos en una lista estructurada de “aquí está tu propio registro de los elementos de datos, los tipos y los valores de las cosas que necesitas saber”.
Una vez serializados, los datos pueden ser transmitidos a otro proceso -quizás a través de un bloque de memoria compartido, o a través de una ruta de comunicación a nivel del sistema operativo, a través de un enlace de red, o incluso en código Morse para que cualquiera pueda captarlos- de tal manera que el receptor pueda dar sentido a los datos, y desempaquetarlos de forma independiente, sin necesidad de saber nada sobre el estado interno actual o futuro del proceso del remitente.
Por ejemplo, si A envía a B un blob de 128 bytes, ¿se trata de dos enteros de 32 bits y dos números de coma flotante de 64 bits (4+4+8+8 = 24 bytes hasta ahora), seguidos del único byte 0x67 (103 en decimal), seguido de 103 bytes de texto ASCII (4+4+8+1+103 = 128 bytes en total)?
¿O es un mensaje de texto UTF-8 de exactamente 120 bytes, rellenado con ceros si es necesario para rellenar el espacio, seguido de dos números de 32 bits que denotan la anchura y la altura de la ventana en pantalla en la que se va a mostrar?
Cuando emisor y receptor no están de acuerdo
Como puedes imaginar, malinterpretar los datos que recibes por IPC, o no comprobar si tienen sentido antes de confiar en ellos, podría tener graves consecuencias.
En el primer ejemplo, si el byte de longitud de la cadena denota un tamaño mayor que la cantidad de datos que quedan (por ejemplo, 0xFF en lugar de 0x67), entonces confiar ciegamente en ese byte de tamaño erróneo hará que leas más allá del final del buffer.
En el segundo ejemplo, si el proceso A se olvida de los datos de anchura y altura y envía en su lugar 128 bytes completos de texto UTF-8, entonces “decodificar” ciegamente dos números de 32 bits al final producirá valores incorrectos, quizás incluso peligrosos.
Si se multiplican esos números codificados incorrectamente para calcular cuántos bytes de almacenamiento hay que asignar a la ventana en pantalla, es probable que se estén produciendo problemas de mala gestión de la memoria en algún momento.
Lo ideal sería que los emisores validaran sus salidas de datos de la IPC antes de transmitirlas, y que los receptores revalidaran independientemente sus entradas de la IPC antes de consumirlas y utilizarlas, pero [a] eso no siempre ocurre y [b] incluso cuando ocurre, podrías acabar teniendo problemas si tienes procedimientos de validación inconsistentes en cada extremo.
En otras palabras, la “insuficiente validación de datos” de los datos de la IPC intercambiados por los procesos que cooperan es siempre un error, y podría acabar siendo grave, como en este caso.
¿Qué hacer?
Parchear pronto, parchear a menudo.
En Chrome, comprueba que estás actualizado haciendo clic en el menú de tres puntos > Ayuda > Acerca de Google Chrome, o navegando a la URL especial chrome://settings/help.
La versión de Chrome que buscas (o la versión de Chromium, si utilizas la versión no propietaria de código abierto) es: 105.0.5195.102 o posterior.
En Edge, es Tres puntos > Ayuda y comentarios > Acerca de Microsoft Edge.
La versión de Edge que buscas es: 105.0.1343.27 o posterior.
Las notas de la versión de Google también enumeran una actualización del Canal Estable Extendido, que podrías estar usando si estás en un ordenador proporcionado por el trabajo – como la Versión de Soporte Extendido de Mozilla o ESR, es una versión oficial que se retrasa en las características pero se mantiene al día con los parches de seguridad, por lo que no estás obligado a adoptar nuevas características sólo para obtener parches.
La versión Extended Stable que quieres es: 104.0.5112.114.
Google también acaba de anunciar una actualización de Chrome para iOS, disponible (como siempre) a través de la App Store.
No se menciona si la versión para iOS estaba afectada por el CVE-2022-3075, pero la versión que buscas, en cualquier caso, es la 105.0.5195.100.
(Suponemos que con iOS, Google se refiere tanto a iOS como a iPadOS, que ahora se envían como variantes diferentes del sistema operativo móvil subyacente de Apple).
Hasta ahora no hay nada en las notas de la versión [2022-09-05T13:45Z] sobre Android – comprueba en Google Play si estás al día.
Dejar un comentario