Estensioni immagine HEIF Microsoft (msheif_store.dll): sotto-allocazione del buffer di origine nel percorso CopyPixels causa lettura fuori dai limiti e Access Violation (DoS)

Durante la decodifica di un'immagine HEIF appositamente predisposta tramite WIC, il codec msheif alloca un buffer di origine di 1 byte ma successivamente tenta di copiare una quantità molto grande di dati pixel da tale buffer durante CopyPixels. La copia usa memmove con una dimensione derivata da stride × altezza ROI, senza convalidare la lunghezza effettiva del buffer di origine. Ciò causa una lettura fuori dai limiti e un'immediata Access Violation (crash). Nella pratica, l'apertura o l'anteprima dell'HEIF dannoso provoca un denial of service in qualsiasi consumer WIC che instrada attraverso HEIF Image Extensions.

Nota sui nomi: i nomi di variabile come roi_height sono dedotti dal disassemblaggio per leggibilità e non riflettono i nomi dei simboli del vendor.

1. Analisi della causa principale

   a. Descrizione dettagliata della vulnerabilità

   • La pipeline di decodifica calcola una lunghezza di copia elevata per memmove basata sulla geometria dell'immagine (es., copy_size = stride * abs(roi_height)).
   • Il buffer di origine che dovrebbe contenere i dati del frame/item decodificato è sotto-allocato a 1 byte, perché:
     • CHEIFStreamReader_ReadItemData chiama CHEIFItemInfoEntry_GetDataSize per calcolare la lunghezza dei dati dell'item.
     • In uno specifico ramo di errore, CHEIFItemInfoEntry_GetDataSize restituisce successo ma lascia la dimensione calcolata a 0.
     • CHEIFStreamReader_ReadItemData quindi chiama MFCreateMemoryBuffer(0, &ppBuffer). Secondo il comportamento di MF, questo produce un buffer con un'allocazione minima di 1 byte.
   • A valle, CopyPixels valida la dimensione del buffer di destinazione ma non valida la lunghezza del buffer di origine rispetto alla dimensione di copia richiesta prima di chiamare memmove.
   • Risultato: memmove(dst, src, large_size) legge molto oltre i byte di src (1 byte), causando un fault nel caricamento vettoriale.

   Questo bug è inoltre aggravato se la larghezza dell'immagine/ROI viene interpretata erroneamente (es., 0x01000100 = 16,777,472), aumentando lo stride e la dimensione finale della copia. Tuttavia, la vulnerabilità principale è che la lunghezza dell'origine non viene verificata rispetto alla lunghezza di copia calcolata.

(7de0.78e4): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
msheif_store!DllCanUnloadNow+0x228b1d:
00007ffd`841bc45d c5fe6f02        vmovdqu ymm0,ymmword ptr [rdx] ds:000002b0`65be6ff0=c0

0:000> !heap -p -a rdx
    address 000002b065be6ff0 found in
    _DPH_HEAP_ROOT @ 2b05bed1000
    in busy allocation (  DPH_HEAP_BLOCK:         UserAddr         UserSize -         VirtAddr         VirtSize)
                             2b062c2f2d8:      2b065be6ff0                1 -      2b065be6000             2000
    ...
    00007ffe75b90563 MFPlat!operator new+0x0000000000000023
    00007ffe75b83d36 MFPlat!MFCreateMemoryBuffer+0x0000000000000056
    00007ffd840157b1 msheif_store!DllCanUnloadNow+0x0000000000081e71
		...

0:000> r r8
r8=0000000001000100

b. Flusso del codice dall'input

0:000> k
 # Child-SP          RetAddr               Call Site
00 0000005d`6a9aed98 00007ffe`6fdefcc2     msheif_store!DllCanUnloadNow+0x228b21
01 0000005d`6a9aeda0 00007ffe`6fcb3adc     msheif_store!DllCanUnloadNow+0x18c382
02 0000005d`6a9aee00 00007ffe`6fcb4513     msheif_store!DllCanUnloadNow+0x5019c
03 0000005d`6a9aeef0 00007ffe`6fcb96da     msheif_store!DllCanUnloadNow+0x50bd3
04 0000005d`6a9af0a0 00007fff`318551d5     msheif_store!DllCanUnloadNow+0x55d9a
05 0000005d`6a9af1a0 00007fff`318082eb     windowscodecs!CPyramidBase::CopyPixels+0xf5
06 0000005d`6a9af260 00007fff`31857e52     windowscodecs!CFormatConverter::CopyPixels+0x22b
07 0000005d`6a9af3e0 00007ff6`15fb0f5d     windowscodecs!CFormatConverterResolver::CopyPixels+0xc2
08 0000005d`6a9af480 00007ff6`15fb04ab     heif_decoder!HEIF_LoadBitmapFromMemory+0x34d [C:\\\\Users\\\\test\\\\source\\\\repos\\\\heif_decoder\\\\heif_decoder\\\\heif_decoder.cpp @ 256]
09 0000005d`6a9af670 00007ff6`15fb1754     heif_decoder!HEIF_FuzzMemory+0x9b [C:\\\\Users\\\\test\\\\source\\\\repos\\\\heif_decoder\\\\heif_decoder\\\\heif_decoder.cpp @ 357]
0a 0000005d`6a9af830 00007ff6`15fb3039     heif_decoder!wmain+0x394 [C:\\\\Users\\\\test\\\\source\\\\repos\\\\heif_decoder\\\\heif_decoder\\\\heif_decoder.cpp @ 524]
0b 0000005d`6a9afaa0 00007ff6`15fb2ee2     heif_decoder!invoke_main+0x39 [D:\\\\a\\\\_work\\\\1\\\\s\\\\src\\\\vctools\\\\crt\\\\vcstartup\\\\src\\\\startup\\\\exe_common.inl @ 91]
0c 0000005d`6a9afaf0 00007ff6`15fb2d9e     heif_decoder!__scrt_common_main_seh+0x132 [D:\\\\a\\\\_work\\\\1\\\\s\\\\src\\\\vctools\\\\crt\\\\vcstartup\\\\src\\\\startup\\\\exe_common.inl @ 288]
0d 0000005d`6a9afb60 00007ff6`15fb30ce     heif_decoder!__scrt_common_main+0xe [D:\\\\a\\\\_work\\\\1\\\\s\\\\src\\\\vctools\\\\crt\\\\vcstartup\\\\src\\\\startup\\\\exe_common.inl @ 331]
0e 0000005d`6a9afb90 00007fff`3847e8d7     heif_decoder!wmainCRTStartup+0xe [D:\\\\a\\\\_work\\\\1\\\\s\\\\src\\\\vctools\\\\crt\\\\vcstartup\\\\src\\\\startup\\\\exe_wmain.cpp @ 17]
0f 0000005d`6a9afbc0 00007fff`3939c34c     KERNEL32!BaseThreadInitThunk+0x17
10 0000005d`6a9afbf0 00000000`00000000     ntdll!RtlUserThreadStart+0x2c

Chiamate interne risolte (rinominate per chiarezza):

CWICHeifDecoderFrame::CopyPixels
 → CWICHeifBitmapSourceBase::CopyPixels_Transform
   → CWICHeifBitmapSourceBase::CopyPixels_Base
     → sub_7FFD8411FC40  // issues memmove
       → memmove         // AV (vmovdqu load from src)

c. Dimensione del buffer

• HEIF appositamente predisposto che porta CHEIFItemInfoEntry_GetDataSize a intraprendere un percorso di "successo con size 0" (es., quando sub_7FFD8408B898 fallisce e la funzione restituisce successo con sizeBuffer = 0).

• Buffer di origine: allocato tramite MFCreateMemoryBuffer(0) ⇒ 1 byte.

• Dimensione di copia: derivata come copy_size = stride * abs(roi_height). Con una larghezza interpretata erroneamente (es., 0x01000100) e un tipico BPP, lo stride è enorme, portando a una copy_size molto grande.

• Chiamata vulnerabile:

  root@kitploit:~

  __int64 sub_7FFD8411FC40(__m128i* dst, __int64 a2, __m128i* src, int a4,
                           unsigned int stride, unsigned int abs_roi_height)
  {
    if (src && dst) {
      if (stride == a2 && stride == a4) {
        // No validation that 'src' contains at least (stride * abs_roi_height) bytes
        memmove(dst, src, (size_t)abs_roi_height * stride); // AV here
      }
    }
  }
  

• Perché l'origine è di 1 byte (percorso di allocazione):

  root@kitploit:~

  __int64 __fastcall CHEIFStreamReader_ReadItemData(__int64 *a1, __int64 *a2, IMFMediaBuffer **a3)
  {
    ppBuffer = 0i64;
    if ( v7(a2) )
    {
      *cbMaxLength = 0i64;
      result = (*(*a2 + 0xA0))(a2, cbMaxLength); // CHEIFItemInfoEntry_GetDataSize
      if ( result < 0 )
      {
        goto LABEL_10;
      }
      if ( *cbMaxLength > 0xC800000ui64 )
      {
        result = 0xC00D36BE;
        goto LABEL_23;
      }
      // cbMaxLength may still be 0 if GetDataSize returned success early
      result = MFCreateMemoryBuffer(cbMaxLength[0], &ppBuffer);
      if ( result < 0 )
      {
        goto LABEL_34;
      }
      ...
  }
  

  root@kitploit:~

  __int64 __fastcall CHEIFItemInfoEntry_GetDataSize(__int64 a1, unsigned __int64 *sizeBuffer)
  {
  
    if ( sizeBuffer )
    {
      *sizeBuffer = 0i64;
      DataLocationInfo = (*(*v5 + 0x78i64))(v5, 0x6D657461i64, &v32);
      if ( DataLocationInfo >= 0 )
      {
        v13 = v32;
        v14 = *(v32 + 0xF0);
        if ( v14 )
        {
          if ( !sub_7FFD8408B898((v14 + 0xC8), (a1 - 0x78), &v33, v31) )
          {
          // returns success (0/S_OK) without updating sizeBuffer
  	      // caller treats this as length=0 → MFCreateMemoryBuffer(0)
  	          DataLocationInfo = 0;
  	          goto LABEL_62;
  	        }
          v17 = v33;
          DataLocationInfo = CHEIFItemInfoEntry_GetDataLocationInfo(v5, v13, *(v33 + 16), &v29, &v30);
          if ( DataLocationInfo >= 0 )
          {
            for ( i = 0; ; ++i )
            {
              if ( i >= *v17 )
              {
                *sizeBuffer = v6;
                goto LABEL_62;
              }
              v21 = *(*(v17 + 8) + 24i64 * i + 16);
              }
              if ( v21 + v6 < v6 )
                break;
              v6 += v21;
              DataLocationInfo = 0;
            }
  
           ...
           ...
  LABEL_62:
    sub_7FFD83F91AEC();
    return DataLocationInfo;
  }
  

d. Correzioni suggerite

Nel percorso CopyPixels, convalidare che il buffer di origine abbia almeno stride * abs(roi_height) byte (e che src_stride/src_height soddisfino o superino la regione richiesta). In caso contrario, fallire con WINCODEC_ERR_INSUFFICIENTBUFFER (o equivalente).

e. Metodologia di analisi (ricostruzione dei simboli)

Per rendere revisionabile il flusso di chiamate, abbiamo ricostruito i nomi delle funzioni interne in IDA a partire dalle stringhe di logging del codec stesso.

• Obiettivo. Identificare nomi di funzione leggibili per le routine chiave (…CopyPixels_Base, …CopyPixels_Transform, CHEIFStreamReader::ReadItemData, ecc.) per allineare lo stack del crash con il codice decompilato.

• Procedura:

  1. Trovare l'helper di logging: nella vista decompilata dei chiamanti attorno al crash, individuare un piccolo helper invocato con un

     argomento stringa costante

     che somiglia a un nome di funzione (es., "CWICHeifBitmapSourceBase::CopyPixels_Base").

     • In IDA: aprire la funzione al crash, salire di un frame e ispezionare le chiamate all'ingresso della funzione per un helper che accetta un letterale stringa.

  2. Raccogliere i chiamanti: usare gli xref verso quell'helper per elencare tutte le funzioni chiamanti.

  3. Estrarre i nomi: per ogni chiamante, aprire la vista decompilata e leggere il secondo argomento dell'helper (il letterale stringa). Questa stringa contiene costantemente il nome di funzione previsto.

  4. Rinominare i chiamanti: in ogni chiamante, premere N (Edit → Rename) e impostare il nome della funzione sulla stringa recuperata (es., CWICHeifBitmapSourceBase::CopyPixels_Base).

  5. Ripetere per i frame vicini finché l'intera catena del crash non ha nomi significativi.

Convalida. Dopo la rinomina, ripercorrere i siti di chiamata e confermare che i tipi/comportamenti degli argomenti corrispondano alle etichette (es., …CopyPixels_Base è dove avvengono i calcoli di stride/ROI e la successiva chiamata a memmove).

2. Prova di concetto

• prerequisiti: HEIF Image Extensions dallo Microsoft Store installate/abilitate (necessarie per la decodifica HEIC/HEIF).

• Passaggi per la riproduzione

  1. Scaricare e salvare il file PoC allegato (../access_violation_0000xxxxxxxxx461_00000xxxxxxxx6B0_1.heif) in una cartella locale.

  2. Assicurarsi che HEIF Image Extensions sia installato (aprire Microsoft Store → cercare "HEIF Image Extensions" → Installa).

  3. Aprire il file PoC con Microsoft Photos (fare doppio clic sul file se Foto è l'app predefinita, oppure Tasto destro → Apri con → Foto).

• Link di download del software

  HEIF Image Extensions (Microsoft Store) https://apps.microsoft.com/detail/9pmmsr1cgpwg?hl=en-US&gl=US