CVE-2023-40477 Vulnerabilidad de ejecución remota de código WinRAR 0Day PoC

“Game of Rars” – Explorando una nueva vulnerabilidad de ejecución remota de código en WinRAR con una prueba de concepto

WinRAR, con más de 50 mil millones de usuarios, se enfrenta a nuevas vulnerabilidades (CVE-2023-40477, CVE-2023-38831).
Hoy presentamos por primera vez: una PoC para CVE-2023-40477.
Aunque se cree que RCE es explotable, su implementación no parece prometedora por varias razones.
Presentamos aquí un estudio exhaustivo de la tecnología: su impacto, escenarios explotables y medidas de mitigación.
La vulnerabilidad se solucionó en el reciente WinRAR v6.23 y aquí también ofrecemos una mitigación alternativa.

CVE-2023-40477: descripción técnica y prueba de concepto

El 2 de agosto, se lanzó Winrar 6.23 con algunas advertencias vagas sobre vulnerabilidades críticas.

Lo que sí sabemos es que la vulnerabilidad (CVE-2023-40477) se ha solucionado, como se muestra en la imagen:

Equipado con BinDiff, IDA y Notepad, profundicemos.

Comparar archivos binarios

Sabemos que la v6.23 tiene la vulnerabilidad solucionada, así que intentemos encontrar las versiones previa y posterior a la corrección para que podamos observarla. winrar-v6.22 y winrar-v6.23:

Título Estructura de directorios Winrar y archivos interesantes.

Se puede observar que winrar.exe es solo una GUI, si es una vulnerabilidad en la descompresión, también puede existir en "unrar.exe". La comparación de 6.23 y 6.22 proporciona las siguientes diferencias:

En 6.23, mirar el diagrama de flujo me dio un par de adiciones interesantes (en el diagrama de funciones grande, se parece al extracto principal):

Bindiff avanzado en adición de extractos

Mirando de cerca, ¡estos parecen ser controles adicionales!

Interesantes bloques adicionales x86 de Bindiff

¡Esto parece prometedor! ¡Vemos algunas comprobaciones adicionales aquí para var <255! Curiosamente, parece que aquí hay permisos de verificación desbordados.
Entonces, es hora de activar (es decir, cambiar los bytes a su valor máximo).

He visto el formato RAR y por la descripción sabemos que está relacionado con los volúmenes de recuperación RAR4 (¿vol3?),
así que generé el RAR4 con estas propiedades y me dio una lista de archivos como esta:

Archivo RAR.RAR
archivo_rar_r00
Versión RAR_FILE00.rev
archivo_rar_r01
Versión RAR_FILE01.rev

Intenté forzar la eliminación del contenido de cualquier valor "similar a un byte" en los volúmenes ".rev" y "rXX" sin éxito. No desencadena ni cambia nada.
Luego intenté buscar en Google algún código fuente "unrar". ¿Quizás exista como parte de algún otro proyecto? !
Así que encontré con éxito este antiguo repositorio: https://github.com/aawc/unrar

Al observar el código fuente, vemos múltiples selecciones constantes "255", específicamente en "recvol3.cpp" , que también aparecen en el original. 6.22 código fuente, entonces tal vez se agregó código fuente adicional debido a... ¿desbordamiento?
Comprobémoslo y, profundizando un poco más, descubrí que la verificación de seguridad en realidad está relacionada con 0xff/255.

lagunas

CVE-2023-40477 en el encabezado recvol3.cpp

Aquí, P[i] se extrae del propio archivo ".rev" . Se encuentran al final del archivo.
Estos P[i] se utilizan para determinar qué volumen de recuperación representan y en qué número de archivo encajan.
FileNumber también se recupera de ellos en P[2] .
Inmediatamente después, el Archivo* se asigna y se coloca en el índice de la matriz que controlamos de tamaño 256. (Línea 241).
Esto explica los 255 cheques.
Porque el índice es en realidad igual a: P[2]+P[0]-1 . Podemos controlarlo casi arbitrariamente a través del contenido del volumen "rev".
Entonces, después de todo, podemos sobrescribir ese búfer con punteros (que apuntan a estructuras de archivos ) y sobrescribirán las siguientes propiedades en el objeto actual.

prueba de concepto

Para activar la vulnerabilidad, descubrimos que es necesario llamar a "Restore()" en recvol3.cpp.
También descubrimos que se requiere un paso de reconstrucción, por lo que parte de eso se realizará sobrescribiendo los punteros.

Para hacer esto, es necesario que estén disponibles algunos volúmenes rar faltantes (falta .r00) y volúmenes .rev.
Además, debemos asegurarnos de que la suma de comprobación crc32 sea correcta.

Para mayor comodidad, generamos el volumen de recuperación rar4 original usando la GUI, que ciertamente puede ser más pequeño y más eficiente, y posiblemente contenga 2 o 3 archivos como máximo.


# 1. re-generate malformed recovery vols.
data = open('%s01.rev' % ARCHIVE_NAME, 'rb').read() # just use the first and malform it up.
names = ['%s%s.rev' % (ARCHIVE_NAME, str(i).zfill(2)) for i in range(256)]
# "destroy" the P[i]'s
datas = [data[:-7] + bytes([0xf0, 0x00, i]) + calc_crc(data[:-7] + bytes([0xf0, 0x00, i])) for i in range(256)]

# 2. overwrite malformed recovery vols.
for i in range(256):
	fname = names[i]
	data = datas[i]
	open(fname, 'wb').write(data)

Sin embargo, también vimos la vulnerabilidad CVE-2023-40477 en el sitio web de rar-labs , lo que probablemente confirma nuestros hallazgos.

Hemos bloqueado exitosamente winrar/unrar en las siguientes situaciones :

1. Memset sobrescribe la memoria no válida (posiblemente después del búfer) con ceros:

Posible desbordamiento del montón en winrar.exe al usar "extraer a"

disponibilidad

Para determinar la explotabilidad, veamos la estructura que cubrimos después de la matriz 256.
Determinemos cómo un atacante podría usar esta primitiva para obtener RCE y qué mitigaciones existen.

// RecVolume3 struct - that gets overflowed
class RecVolumes3
{
  private:
    File *SrcFile[256]; // overflow in here with File* pointers.
    Array Buf;

#ifdef RAR_SMP
    ThreadPool *RSThreadPool;
#endif
  public:
    RecVolumes3(CommandData *Cmd,bool TestOnly);
    ~RecVolumes3();
    void Make(CommandData *Cmd,wchar *ArcName);
    bool Restore(CommandData *Cmd,const wchar *Name,bool Silent);
    void Test(CommandData *Cmd,const wchar *Name);
};
...
...
// Array template class:
template  class Array
{
  private:
    T *Buffer;
    size_t BufSize;
    size_t AllocSize;
    size_t MaxSize;
  public:
    Array();
    Array(size_t Size);
    Array(const Array &Src); // Copy constructor.
    ~Array();

El puntero "Archivo*" se utiliza aquí para desbordar el objeto "Buffer".

Afortunadamente, existen muchas protecciones: ASLR, CFG, Stack-Cookie y DEP.

Esto ni siquiera menciona las diferencias binarias entre las versiones de Winrar. Todo esto hace que la explotación sea posible, pero poco probable para el actor de amenazas promedio.

Influencia

A pesar de su alta calificación CVE, la complejidad requerida para una explotación exitosa sugiere que el potencial de abuso generalizado es bajo, a diferencia de la vulnerabilidad Log4j RCE ampliamente explotada.

Curiosamente, Chromium también parece utilizar la biblioteca unrar: https://chromium.googlesource.com/chromium/src//6ff23b0604e2edbe7ef282564ea340f5c72ab91a^/

La biblioteca unrar está legítimamente incorporada en Chrome OS como una dependencia de terceros, aunque no hay referencias de código que muestren su uso.

Medidas de atenuación

En términos de estrategias de mitigación, existen varias opciones viables a considerar:

Solución completa: actualizar Winrar a 6.23+ solucionará completamente el problema.
Solución: si las actualizaciones no están disponibles o son difíciles de implementar, bloquee los archivos *.rev (preferiblemente también bloquee: archivos *.rXX y *.partXX.rar). Esta puede ser una solución rápida, aunque no está del todo confirmada ni es oficial.

Descarga completa del proyecto

[Descarga CSDN] https://download.csdn.net/download/qq_39190622/88291093

¿Cómo probar?

Puede generar su propio PoC o simplemente probar el archivo RAR de demostración incluido (verificado para que falle winrar-6.22 después de descomprimirlo).

Generación PoC- cve_2023_40477_poc.py
Archivo RAR de demostración: solo extraiga Rar.rar del 示例 poc_after_gen directorio.