Disattivazione dell'audio: concatenamento delle vulnerabilità per ottenere RCE su Outlook: Parte 2

Superfici di attacco

Il file audio che verrà riprodotto da Outlook è in formato WAV (Waveform Audio File). Viene riprodotto tramite la funzione PlaySound , che riceve il percorso del file audio. PlaySound caricherà il file, lo analizzerà e quindi chiamerà soundOpen che chiamerà le diverse funzioni Wave, ad esempio waveOutOpen.

I file WAV fungono da container (o contenitore) per più codec audio. Un codec è un programma o un codice che codifica o decodifica un flusso di dati (come immagini, video o audio). Di solito, il codec sarà la codifica PCM che rappresenta un modo semplice per rappresentare segnali analogici campionati.

Esistono tre principali superfici di attacco in cui possiamo cercare le vulnerabilità:

1. analisi del formato WAV

2. Audio Compression Manager 

3. diversi codec audio

analisi del formato WAV

L'analisi del formato WAV è implementata all'interno della funzione soundInitWavHdr in winmm.dll (la libreria che implementa l'API multimediale di Windows). La superficie d'attacco lì presente non è ampia e sembra essere stata rivista; non è stata riscontrata alcuna vulnerabilità.

Ogni driver ACM deve implementare funzioni quali acmdStreamSize e acmdStreamOpen. Il primo restituisce la dimensione (in byte) necessaria per l'output della conversione; il secondo crea una struttura del flusso e imposta i campi appropriati, come la funzione di callback di decodifica.

La superficie di attacco di ACM non è molto ampia. Tuttavia, siamo riusciti a trovare una vulnerabilità in quel codice, come mostreremo più avanti in questo post del blog.

diversi codec audio

Per l'ultima superficie di attacco, abbiamo diversi codec audio installati per impostazione predefinita. Il codec viene specificato nel file WAV utilizzando due modi diversi:

1. wFormatTag nella parte FORMAT

2. Se wFormatTag è WAVE_FORMAT_EXTENSIBLE, SubFormat manterrà il GUID per il codec audio.

L'elenco dei codec disponibili è descritto nell' Appendice.

Nozioni fondamentali sull'elaborazione del segnale audio

Prima di esaminare il codice, acquisiamo familiarità con alcune nozioni fondamentali sull'elaborazione del segnale audio. Se avete già familiarità con questi concetti, non esitate a passare alla sezione successiva.

Quando sentiamo il suono, ciò che effettivamente sentiamo è una vibrazione che si propaga tramite un mezzo di trasmissione. Il suono è la ricezione di quelle onde di vibrazione captate dalle nostre orecchie e percepite dal nostro cervello.

Un segnale audio è una forma d'onda continua. Per elaborarlo digitalmente, dobbiamo convertirlo da un segnale analogico a un segnale digitale (ad esempio, utilizzando un convertitore ADC). Questa conversione è la "discretizzazione" del segnale analogico. Per farlo, campioniamo il segnale analogico più volte in punti dati equidistanti (chiamati campioni). La velocità di campionamento (nota anche come frequenza di campionamento) determina il numero di campioni prelevati al secondo. Frequenze di campionamento più elevate catturano più dettagli, ma richiedono anche una maggiore capacità di archiviazione ed elaborazione.

Oltre alla frequenza di campionamento, abbiamo la dimensione del campione, ovvero quanti bit vengono utilizzati per ciascun campione. Ancora una volta, maggiore è la dimensione del campione, migliore sarà la qualità (o più simile al suono originale) del campione. Le dimensioni dei campioni sono generalmente di 16 bit o 24 bit a campione.

I codec audio si basano su modelli psicoacustici. La psicoacustica è lo studio scientifico della percezione del suono e dell'audiologia, ovvero il modo in cui il sistema uditivo umano percepisce i vari suoni. Ad esempio, il campo uditivo umano è compreso tra 20 Hz e 20.000 Hz. Pertanto, per ridurre ulteriormente le dimensioni del file, i codec audio potrebbero eliminare le frequenze non udibili dagli esseri umani. Inoltre, il codec audio può eliminare i segnali se il loro volume non è abbastanza forte da poter essere udito dall'orecchio umano. Ad esempio, un suono a 20 Hz non verrà udito se è inferiore a 60 decibel.

Esistono molti altri esempi di modelli psicoacustici; ad esempio, il mascheramento di segnali silenziosi quando in caso di frequenza o tempo vicini a un segnale forte.

L'analisi, l'interpretazione e la modifica dei segnali vengono eseguite utilizzando banchi di filtri, che dividono il segnale in sottobande: bande distinte di componenti che consentono un esame e una manipolazione più dettagliati di porzioni specifiche del segnale. I banchi di filtri comunemente utilizzati sono i banchi di filtri DCT e polifase.

Con queste nozioni fondamentali, possiamo esaminare in modo approfondito la ricerca di diversi codec.

La maggior parte delle operazioni eseguite come parte del processo di decodifica MP3 sono complesse e, sebbene in teoria potrebbero essere un posto interessante (e attraente) in cui cercare vulnerabilità sottili, in pratica molte delle operazioni (come il DCT modificato, il banco di filtri polifase e la riduzione degli alias) viene eseguita su un buffer che mantiene costantemente i valori per 576 campioni.  Pertanto, trovare una vulnerabilità di scrittura fuori qui non è plausibile. Un posto interessante è la decodifica Huffman, poiché naturalmente funziona su dati più dinamici (al contrario del buffer di 576 campioni).

Ogni regione ha le proprie tabelle di Huffman (ad eccezione della regione 0) e quindi i campioni di frequenze diverse sono codificati in modo diverso.

La classificazione dei campioni in regioni si basa sulle seguenti variabili:

• big_values: specifica il numero totale di campioni presenti nella regione dei valori elevati

• region0_count e region1_count: partiziona big_values in sottoregioni; sottraendo la loro somma da big_values si ottiene il numero di campioni nella regione 2.

• part2_3length: specifica quanti bit vengono utilizzati per i fattori di scala (parte 2) e quanti per la codifica Huffman (parte 3)

Il processo di decodifica dei 576 campioni avviene come segue:

• Decodifica dei campioni nella regione big_values

• Decodifica dei campioni nella regione count1

• Se il numero di bit elaborati è maggiore di part2_3length, abbiamo praticamente decodificato tutti i dati di input e persino i dati over-read: pertanto, sottraete 4 da total_samples_read (ovvero, scartate questi bit di input)

• Se sono rimasti campioni, inserite uno 0 (questo forma la regione 0)

Questa logica nella Tabella 1 viene mostrata come pseudocodice.

Tabella 1: Pseudo-codice della logica di decodifica Huffman

Sfortunatamente, nel codice manca un caso limite specifico, e ciò comporta un underflow dei numeri interi.

• La dimensione della regione dei valori elevati è 0

• La dimensione della regione Count1 è 0

• Part2_3length è 0

• Bits_processed è maggiore di 0

In questo caso specifico, bits_processed sarà maggiore di part2_3length (raggiunge un valore diverso da zero prima del processo di decodifica durante la decodifica dei fattori di scala). Pertanto, il codice "scartare" gli ultimi quattro campioni. Poiché il codice non ha elaborato alcun campione, total_samples_read è 0. Qui si verificherà un underflow e il codice considera che abbiamo elaborato -4 campioni. Per cui riempirà la regione 0 come segue:

• Imposta il puntatore del buffer su &samples[total_samples_read]. Questo punta a 16 byte prima buffer dei campioni.

• Impostate la dimensione di scrittura come 576 - total_samples_read = 576 - (-4) = 580 numeri interi.

Pertanto, abbiamo una scrittura fuori banda immediatamente prima del buffer dei campioni con il valore zero. Bene!

Allora perché a questa vulnerabilità non è stata assegnata una CVE? Il buffer dei campioni fa parte di una struttura e il campo subito prima del buffer dei campioni è l'array del fattore di scala. Questo è un array con campi che già controlliamo e quindi non vi è un impatto davvero interessante qui.

La stessa vulnerabilità si verifica anche dopo che il codice ha dequantizzato i campioni. Riempie ancora una volta la regione 0, questa volta con il buffer dequantizzato. Volete sapere cosa c'è prima del buffer dequantizzato? Il buffer dei campioni decodificati da Huffman. Questo è lo stesso buffer di campioni che abbiamo descritto in precedenza, sul quale abbiamo anche il controllo. Quindi, ancora una volta, non c'è un impatto reale.

Queste scritture fuori banda esistono ancora nel decoder MP3 (accessibili sia tramite WAV che tramite file .mp3) e secondo Microsoft potrebbero essere risolte in futuro. Sebbene non sia stata rilevata alcuna vulnerabilità di impatto durante la decompilazione del codec, riteniamo che potrebbero esserci delle vulnerabilità che si nascondono nelle diverse operazioni complesse effettuate dal decoder.

Secondo tentativo: overflow di numeri interi nel codec IMA ADPCM

Il nostro prossimo tentativo sarà il codec IMA ADPCM, implementato in imaadp32.acm. Come ora sappiamo, l'ACM gestirà le conversioni da e tra diversi codec. Per registrare un codec, il codice deve implementare le funzioni ACM. Una di queste funzioni è acmStreamSize, che restituisce il numero di byte necessari per il buffer di destinazione.

Il codec IMA ADPCM calcola la dimensione del buffer di destinazione in base alla dimensione del payload di input (cbSrcLength), l'allineamento (nBlockAlign) e i e campioni per blocco (wSamplesPerBlock; Tabella 2).

Tabella 2. Calcolo della dimensione del buffer

Prima di eseguire la moltiplicazione, il codice verifica che il calcolo non provochi un overflow di numeri interi (Tabella 3).

Tabella 3: Controllo di calcolo inteso a prevenire l'overflow di numeri interi

Apparentemente questo controllo non è sufficiente per evitare un overflow. Se c'è un avanzo nella divisione di cbSrcLength / pwfxSrc->nBlockAlign, il codice incrementa il risultato di (cbSrcLength / pwfxSrc->nBlockAlign), che viene utilizzato nella moltiplicazione. Il controllo di overflow non copre questo incremento. Di conseguenza, possiamo ancora superare la lunghezza del buffer di destinazione specificando valori personalizzati.

Dobbiamo fornire cbSrcLength che abbia un avanzo quando viene diviso per pwfxSrc->nBlockAlign.

La tabella 4 mostra un esempio di valori che portano a un overflow di numeri interi.

Tabella 4. Esempio di valori che producono un overflow di numeri interi

Ciò produce un buffer di destinazione di 0xE byte, mentre il buffer di destinazione dovrebbe essere molto più grande.

Anche se questo sembra un overflow di numeri interi che può generare una scrittura fuori banda, la funzione di decodifica si assicura correttamente che non avvengano scritture dopo il buffer allocato e non presuppone che il buffer sia stato allocato con la dimensione corretta.

Quindi, nonostante forniamo più campioni, in pratica quando il buffer di destinazione è pieno, il codice si ferma. Lo stesso comportamento si verifica nel codec AD PCM (implementato in msadp32.acm(Secure Access Service Edge).

Questo è un problema sfruttabile. Possiamo fare in modo che GlobalAlloc allochi un buffer veramente piccolo invece di uno grande facendo sì che acmStreamSize restituisca un valore compreso tra 0xffffff50 e 0xffffffff. Dopo questa allocazione possiamo causare due scritture fuori banda:

1. I valori dell'intestazione del flusso, ad esempio la dimensione della struttura, i puntatori e le dimensioni del buffer di origine e destinazione. Questi valori sono parzialmente controllabili.

2. I valori decodificati del codec. Questi valori sono completamente controllati.

Per attivare la vulnerabilità dobbiamo fornire un campione WAV con una dimensione, una volta decodificato, che sarà maggiore o uguale a 0xffffff50. Anche se sembra facile da realizzare, durante i nostri tentativi abbiamo riscontrato che potrebbe non essere possibile ottenerlo con alcuni codec. Ad esempio, con il codec MP3, il calcolo include una moltiplicazione per 1.152 o 576 (che è il numero di campioni per fotogramma). Il risultato di quel calcolo non rientrerà mai nell'intervallo che desideriamo.

Alla fine siamo riusciti ad attivare la vulnerabilità utilizzando il codec IMA ADP. La dimensione del file è di circa 1,8 GB. Eseguendo l'operazione di limite matematico sul calcolo possiamo concludere che la dimensione minima del file possibile con il codec IMA ADP è 1 GB. 

Lo sfruttamento di tale vulnerabilità è reso più semplice quando è disponibile un motore di scripting per creare dinamicamente un exploit. Poiché Windows Media Player non ne ha uno, lo sfruttamento può essere più impegnativo. Ciò potrebbe essere ancora possibile, come dimostrato da Chris Evans nel suo post sul blog "Advancing exploitation: a scriptless 0day exploit against Linux desktops(Sfruttamento avanzato: un explot 0day senza script contro i desktop Linux). Tuttavia, esistono diverse possibilità che questa vulnerabilità venga sfruttata con successo nel contesto dell'applicazione Outlook (o altre applicazioni di messaggistica istantanea).