Chrome corrige una vulnerabilidad de desbordamiento de búfer en el heap de WebP

 (chromereleases.googleblog.com)
1 puntos por GN⁺ 2023-09-13 | 1 comentarios | Compartir por WhatsApp
  • Se distribuyó una actualización para los canales Stable y Extended Stable de Chrome para escritorio que incluye una corrección para una vulnerabilidad de desbordamiento de búfer en el heap de WebP
  • Las nuevas compilaciones son 116.0.5845.187 en Mac y Linux, y 116.0.5845.187/.188 en Windows, con un despliegue gradual a lo largo de varios días o semanas
  • Esta versión incluye 1 corrección de seguridad, y CVE-2023-4863 está clasificada como Critical
  • Apple SEAR y The Citizen Lab de la Munk School de la University of Toronto reportaron la vulnerabilidad el 6 de septiembre de 2023
  • Google indicó que existen casos de explotación activa, y el acceso a los detalles del bug podría permanecer restringido hasta que se aplique la versión corregida

Actualización de canales de Chrome para escritorio

  • Los canales Stable y Extended Stable se actualizaron con nuevas compilaciones para escritorio
  • Las versiones del canal Stable por plataforma son las siguientes
    • Mac: 116.0.5845.187
    • Linux: 116.0.5845.187
    • Windows: 116.0.5845.187/.188
  • El canal Extended Stable también se distribuye con versiones separadas
    • Windows: 116.0.5845.188
    • Mac: 116.0.5845.187
  • La actualización se desplegará gradualmente a lo largo de varios días o semanas
  • La lista completa de cambios de esta compilación puede consultarse en el log

Corrección de seguridad: CVE-2023-4863

  • Esta versión incluye 1 corrección de seguridad
  • La principal corrección aportada por investigadores externos corresponde a la siguiente vulnerabilidad
    • Critical CVE-2023-4863: desbordamiento de búfer en el heap de WebP
    • Número de bug: 1479274
    • Reportado por: Apple Security Engineering and Architecture (SEAR), The Citizen Lab de la Munk School de la University of Toronto
    • Fecha del reporte: 6 de septiembre de 2023
    • Monto de recompensa: $NA

Explotación activa y restricciones de divulgación

  • Google informó que existe un exploit de CVE-2023-4863 en entornos reales
  • El acceso a los detalles del bug y a los enlaces relacionados podría permanecer restringido hasta que la mayoría de los usuarios se actualicen a la versión corregida
  • La restricción también puede mantenerse si el mismo bug existe en una biblioteca de terceros de la que dependen otros proyectos y aún no ha sido corregida

Detección de bugs de seguridad y vías de reporte

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-09-13
Opiniones en Hacker News

  • En Google Chrome, las imágenes WebP se decodifican en el proceso del renderer, así que, aunque un exploit tenga éxito, solo permitiría ejecutar código del renderer dentro del sandbox.
    El renderer es muy complejo y cada año se descubren muchos exploits, pero incluso si se logra ejecutar código en el renderer, no se supera mucho el nivel de permisos que tiene una página web normal.
    En particular, no puede ver ni dejar archivos en el sistema de archivos local, ni leer cookies de otros dominios.

    • Claro que si hubiera un exploit de escape del sandbox para combinarlo con esto, la historia sería otra.
      No es la máxima prioridad inmediata, pero si un exploit así no está ya circulando en la naturaleza, debería parchearse lo antes posible en un momento que no cause demasiadas molestias.
    • En la internet moderna hay una enorme cantidad de imágenes subidas por usuarios, así que con solo obtener los permisos del contexto de usuario de un sitio web ya es algo bastante importante.
      Como no queda limitado a un solo sitio o frontend, se parece más a un XSS potenciado.
    • Estoy usando WebP sin pérdida y es mucho más eficiente que PNG.
      Ah, comenté en el hilo equivocado; quería responder al “jpeg is good enough” de https://news.ycombinator.com/item?id=37479576.
    • ¿Eso significa que el renderer no puede enviar información de vuelta al sitio web?
      Además, aunque hayas desactivado JavaScript, ¿no implicaría que de repente el sitio web todavía puede ejecutar código?

  • Por eso ahora entiendo mejor que los desarrolladores de navegadores sean lentos para adoptar formatos nuevos.
    WebP no tiene grandes ventajas frente a JPEG, sobre todo la transparencia, y su éxito también fue limitado.
    Pero ahora derivó en varios agujeros de seguridad de alta prioridad, y todo lo que esté enlazado con libwebp tendrá que distribuir parches durante el próximo mes.
    No digo que no haya que hacer cosas nuevas, pero creo que los desarrolladores tienden a subestimar bastante los costos.

    • Firefox tiene una capa adicional de sandbox que puede aplicarse a bibliotecas individuales, no a todo el proceso: https://hacks.mozilla.org/2021/12/webassembly-and-back-again...
    • Para ser justos, en el pasado los problemas en bibliotecas de decodificación de JPEG también se usaron como vía para distribuir malware.
      Es cierto que el ecosistema WebP es mucho menos maduro, pero estoy seguro de que el código de manejo de formatos más antiguos también habrá tenido bastantes problemas de seguridad.
      Aun así, el razonamiento es válido. Hasta hace unas semanas, el clima entre los internautas era que había que adoptar JPEG XL lo antes posible y que, para eso, los desarrolladores de navegadores “solo tenían que incluir el código del decodificador de referencia en el código base”, con “casi ningún costo”.
    • Si los navegadores no hubieran adoptado el formato nuevo, ¿se habría descubierto este bug?
      Es muy probable que otros formatos de imagen y bibliotecas también estén llenos de bugs, pero como no se usan en software importante, a nadie le importan.
      Especialmente para alguien con la capacidad de encontrar y explotar este tipo de bugs, la recompensa por el tiempo invertido es mala.
      Que algo no se use durante mucho tiempo no hace que tenga menos bugs.
    • La causa de los agujeros de seguridad no es el formato de imagen nuevo, sino la falta de seguridad de memoria en C/C++.
      Si los codificadores y decodificadores de imágenes, y otros codificadores/decodificadores, no usaran lenguajes inseguros, sería menos probable crear estos bugs.
    • WebP es un formato mucho más complejo que JPEG, y la complejidad se correlaciona casi directamente con la densidad de defectos.
      Aparte de eso, creo que también son un problema la cultura de complicar el código más de lo necesario y los desarrolladores que no entienden bien los detalles.

  • Esta corrección entra en Firefox 117.0.1 y Fenix 117.1.0 de hoy: https://hg.mozilla.org/releases/mozilla-release/rev/e245ca21...

  • Como referencia, el crate image tiene una implementación de un decodificador WebP escrita en Rust seguro: https://github.com/image-rs/image
    Durante mucho tiempo estuvo bastante incompleta, pero el año pasado se implementaron muchas funciones de WebP.
    Como Chromium ahora tiene una política que permite usar dependencias de Rust, ¿no podría Chromium también empezar a adoptarla?

    • Si Chrome tuviera una opción para “usar la versión segura de la biblioteca XYZ, aunque pueda ser más lenta”, la activaría de inmediato aunque aceptara la pérdida de rendimiento.
    • Me parece absurdo que en 2023 se siga escribiendo nuevo código C/C++ para un objetivo con una superficie de ataque tan enorme como un navegador web.

  • Commit original del problema: https://github.com/webmproject/libwebp/commit/f75dfbf23d1df1...
    Commit que corrige este bug: https://github.com/webmproject/libwebp/commit/902bc919033134...
    El commit original optimizaba el decodificador Huffman. Este decodificador usa una optimización conocida: lee N bits por adelantado y decide cuántos bits debe consumir realmente y qué símbolo debe decodificar. O, si se trata de un prefijo de N bits de varios símbolos, decide qué tabla consultar para los bits restantes
    La versión anterior usaba una tabla de consulta para símbolos cortos, pero los símbolos largos requerían recorrer un grafo. La versión nueva lo mejoró usando un arreglo de tablas de consulta. Cada entrada contiene (nbits, value), donde nbits es la cantidad de bits a consumir y value normalmente es el símbolo. Pero si nbits supera N, value se interpreta como un índice de tabla, y nbits se reinterpreta como la longitud del código más largo en ese subárbol. Por eso cada tabla siguiente debe tener 2^(nbits - N) entradas. La tabla raíz siempre queda fija en 2^N entradas
    La nueva versión calculaba la cantidad máxima de entradas (kTableSize) en función de la cantidad de símbolos. Por supuesto, el árbol Huffman proviene de entradas no confiables, y es fácil imaginar casos en los que nbits se vuelve muy grande. VP8 Lossless permite específicamente hasta 15 bits, así que si todas las LUT se mapean a sus propias tablas auxiliares separadas, la tabla máxima posible tiene 2^N + 2^15 entradas. Tampoco hacen falta tantos símbolos para construirla: con 16-N símbolos por tabla alcanza
    Curiosamente, el propio código tenía un modo que solo calculaba el tamaño de la tabla (llamando a VP8LBuildHuffmanTable con root_table == NULL), pero por alguna razón no se usaba y asumía un tamaño máximo fijo. Entonces, si se construía un árbol Huffman para maximizar la cantidad de entradas, se terminaba escribiendo fuera del área asignada
    Se entiende por qué ocurrió esto. La etapa de decodificación Huffman es una de las partes con más carga de cálculo en muchos formatos de compresión, así que incluso pequeñas mejoras importan. La optimización anterior es conocida, pero normalmente se considera que las rutas de códigos largos son poco frecuentes, por lo que tenían baja prioridad de optimización. El mensaje del commit original refutó esa suposición y pudo ser integrado. Es difícil asegurar que un lenguaje con seguridad de memoria hubiera evitado este problema. Porque, rara vez, este es un caso en el que uno se ve tentado a evitar activamente las comprobaciones de overflow
    [1] Sin embargo, la corrupción de memoria ocurre durante la construcción de la tabla, no en un bucle ajustado, así que una comprobación parcial de overflow habría ayudado mucho. La corrección real no cambió en absoluto la función ReadSymbol. Aun así, la seguridad de los bucles ajustados debe justificarse, y una justificación incorrecta puede arruinarlo todo

    • Este componente debería haberse escrito en WUFFS
      Si es cierto que no se necesitan comprobaciones de límites, está bien. WUFFS no emite comprobaciones de límites en tiempo de ejecución
      Pero si, como en este caso, el software estaba equivocado y se salía de los límites, en WUFFS no compilaría
      Se podría pensar “eso es imposible”, y si WUFFS fuera un lenguaje de programación de propósito general, sería correcto. Según el teorema de Rice, toda propiedad semántica no trivial es indecidible
      Por suerte, WUFFS no es un lenguaje de propósito general. La mayoría del software no se puede escribir en WUFFS, pero los códecs de imagen sí
    • Hace más de 10 años que no trabajo como programador en C, y para empezar tampoco era tan bueno, pero por la explicación coincido en que una comprobación de límites habría detectado el problema
      Aunque también me pregunto si habría sido posible crear pruebas automatizadas que detectaran este tipo de problemas
      En el código que manejo personalmente, puedo extraer algunos cálculos a funciones separadas y probarlas de forma independiente. Aquí quizá habría sido difícil por rendimiento, pero no estoy seguro

  • Corrección de una escritura fuera de rango en BuildHuffmanTable
    https://github.com/webmproject/libwebp/commit/902bc919033134...

  • Parece que fue reportado por Apple, y se ve muy parecido a esta actualización de seguridad: https://support.apple.com/en-us/HT213906

    • Lo reportaron Apple y “Citizen Lab de la Munk School de la UoT”, y en la página enlazada aparece exactamente así
      Por eso parece bastante probable. Apple podría estar usando libwebp internamente en ImageIO, o podría haber cometido un error similar
    • Es interesante ver cuán distinta es la reacción entre la semana pasada y ahora

  • Los códecs de imagen tienen una larga historia de vulnerabilidades
    El procesamiento real de imágenes puede ser código lineal bastante limpio, al punto de poder escribirse incluso en FORTRAN IV con seguridad de memoria, pero cuando entra la compresión aparecen muchas estructuras de datos de longitud variable, seguimiento de punteros, etc.
    A eso se suma la presión de que debe ejecutarse rápido

  • ¿Esto también afecta a Electron? Si es así, ¿a qué versiones?

  • ¿Hay alguna vía realista para explotar esto?
    Por lo que escuché, en 64 bits el heap spray ya no es práctico
    ¿Hay algún objeto predecible en memoria que se pueda sobrescribir?

    • Ya se está explotando en la práctica, así que la respuesta es sí
      Incluso en 64 bits, el heap spray claramente se sigue usando en exploits del kernel. No sé bien qué primitivas usa la gente en exploits de V8