Risultati principali
I file binari macOS moderni, spesso, sono dotati di efficaci sistemi di mitigazione delle piattaforme, come PIE, ASLR e la firma del codice. Tuttavia, ci siamo chiesti cosa succede quando un'applicazione moderna viola le vecchie regole POSIX.
Nella nostra analisi del file binario di un wrapper OpenSSL firmato (eseguita tramite "Hallucinator", il nostro strumento di ricerca dell'AI sviluppato internamente), abbiamo individuato una vulnerabilità critica legata ad un segnale rientrato: le funzionalità TLS legacy coesistenti con i dati primitivi di segnale, stdio e memoria, che sono notoriamente pericolosi in contesti asincroni.
Mentre i vincoli ambientali hanno impedito la conferma end-to-end dell'exploit, le nostre prove statiche e dinamiche supportano fortemente una condizione DoS (Denial-of-Service) ad alto rischio, con un'escalation plausibile per una vulnerabilità UAF (Use-After-Free) in caso di tempistiche avverse.
Questo post del blog analizza le prove confermate, esamina il rischio ragionato e spiega perché i responsabili della sicurezza non devono limitarsi agli elenchi di controllo per la conformità quando valutano le minacce all'architettura.
Il confine tra prove e destinazione
Per garantire che questa ricerca rimanga strettamente sostenibile, stiamo intenzionalmente separando ciò che abbiamo osservato direttamente da quello che richiederebbe un'ulteriore strumentazione del runtime.
Metadati di destinazione
Destinazione: openssl (file binario universale macOS Mach-O)
SHA-256: 5a7d226a379afa156ea96068abd51da74f5f86cd2eb5b6b17ac45ee002d340b4
Prova statica confermata
Funzionalità TLS legacy: le prove dei simboli confermano la presenza di _TLSv1_client_method().
Dati primitivi non sicuri in ambienti asincroni: le prove dei simboli confermano la presenza di _signal(), _fprintf() e _free().
Livello di produzione: la firma del codice, gli output hash e i metadati dei file confermano che si tratta di un vero artefatto macOS firmato, non di un codice di test sintetico
Questi tre aspetti stabiliscono un modello di vulnerabilità legata ad un segnale rientrato altamente credibile, che lo trasforma da un avvertimento di analisi statica generica ad una falla architettonica verificata.
Punteggio provvisorio (basato sulle prove attuali): CVSS v3.1 = 5,1 (medio)
Vettore di base consigliato per la richiesta sostenibile di oggi:
CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H Perché il punteggio provvisorio è solo medio?
- Abbiamo forti segnali di debolezza statica, ma nessuna catena di exploit confermata.
- L'impatto è principalmente legato al rischio di disponibilità (potenziale di blocco/arresto).
- Lo sfruttamento appare attualmente molto complesso.
La vulnerabilità principale: confusione nello stato indotto dal segnale
Molti sviluppatori utilizzano un modello di progettazione vulnerabile con timer watchdog. Quando il timer si attiva, l'applicazione tenta di eseguire tre azioni in sequenza:
Registrare l'evento
Pulire la memoria
Uscire dal programma
Lo sviluppatore scrive un fprintf(stderr, "Timeout...") rapido seguito da un free() all'interno dell'handler del segnale, che sembra funzionare perfettamente negli unit test.
Tuttavia, chiamare alcune funzioni come fprintf e free all'interno di un handler del segnale implica una violazione delle regole POSIX async-signal-safety fondamentali.
Quando OpenSSL gestisce transizioni di stato complesse, come ad esempio la disattivazione di una connessione TLS danneggiata, si basa principalmente sull'allocatore della memoria del sistema. Gli handler dei segnali vengono eseguiti in modo asincrono rispetto al normale flusso di controllo. Se un criminale può far ritardare la risposta di un pacchetto di rete abbastanza a lungo da attivare il watchdog SIGALRM, l'handler del segnale interromperà bruscamente l'esecuzione intermedia del teardown di OpenSSL.
Se fprintf tenta di allocare dinamicamente lo spazio del buffer mentre il thread principale mantiene ancora il blocco di memoria heap libmalloc durante una pulizia della sessione, lo stato del programma può essere danneggiato. L'impatto pratico e confermato della sicurezza su questa intersezione è costituito da instabilità grave, blocco dei processi e DoS asincrono.
Il catalizzatore: ampliare l'intervallo tramite il downgrade del protocollo
Colpire una condizione microscopica durante la pulizia della memoria è notoriamente difficile. In questo caso, la presenza di _TLSv1_client_method cambia il profilo di rischio.
Gli handshake TLS esistenti sono fondamentalmente più "rumorosi" e pesanti rispetto alle moderne implementazioni TLS 1.3. La logica di gestione degli errori e di invalidazione delle sessioni per le suite di crittografia legacy comporta una pulizia della memoria più estesa all'interno delle strutture interne di OpenSSL.
Forzando attivamente il downgrade di una connessione, un criminale non sta necessariamente tentando di interrompere la crittografia, ma sta spingendo intenzionalmente il sistema di stato OpenSSL nei suoi precedenti percorsi di codice con latenza più elevata. In tal mondo, si allunga teoricamente l'intervallo di esecuzione del teardown, il che aumenta in modo significativo la probabilità di effettuare correttamente l'interruzione del segnale.
La lacuna in termini di sfruttamento: confronto tra DoS e UAF
Nel nostro ambiente di esecuzione attuale, il runtime è stato distrutto in modo aggressivo (uscita 137) durante la convalida e l'allegato lldb è stato limitato. A causa di questi vincoli, non è stato possibile acquisire un segne conclusivo del deadlock o confermare lo sfruttamento deterministico dell'UAF.
- Livello di rischio: alto (impatto sulla disponibilità e potenziale rischio di integrità in caso di stress delle tempistiche)
- Fiducia: medio-alta sull'esistenza del modello di vulnerabilità; media sull'impatto sul danneggiamento della memoria nel caso peggiore
- Conclusione Abbiamo confermato uno schema di rientro ad alto rischio: un file binario moderno e firmato espone catene di vulnerabilità di alto valore quando i percorsi dei protocolli legacy e le ipotesi asincrone erano in collisione
Nell'output delle prove (tmp.txt), lo stesso file binario Mach-O firmato contiene _TLSv1_client_method con _signal, _fprintf e _free. Questa co-presenza è la condizione tecnica fondamentale: percorso di codice legacy compatibile TLS, dati primitivi di gestione del segnale asincrono e utilizzo di libc async-unsafe-adjacent, che insieme confermano lo schema di vulnerabilità della rientranza ad alto rischio.
Demo-openssl-glitch % otool -Iv openssl > tmp.txt 2>&1
Demo-openssl-glitch % cat tmp.txt | grep -En "_TLSv1_client_method| _signal| _fprintf| _free"
620:0x0000000100035c1c 3132 _TLSv1_client_method
919:0x0000000100036ecc 3440 _fprintf
922:0x0000000100036efc 3443 _free
923:0x0000000100036f0c 3444 _freeaddrinfo
924:0x0000000100036f1c 3445 _freezero
1004:0x000000010003741c 3527 _signal
#
1138:0x000000010004c318 3132 _TLSv1_client_method
1923:0x000000010004dba0 3445 _freezero
2010:0x000000010004de58 3440 _fprintf
2013:0x000000010004de70 3443 _free
2014:0x000000010004de78 3444 _freeaddrinfo
2048:0x000000010004df88 3527 _signalIl punto di vista dei CISO: tradurre i difetti tecnici in rischi aziendali
Per i responsabili della sicurezza che si occupano di ambienti complessi, una vulnerabilità di questo tipo pone quattro sfide esclusive che sfuggono ai controlli di conformità standard:
L'interruzione "fantasma" e la crescita esponenziale del tempo medio di risoluzione (MTTR)
L'illusione del "green dashboard"
Il debito tecnologico legacy come leva per lo sfruttamento
La moltiplicazione delle minacce all'intelligenza artificiale (democratizzazione degli exploit complessi)
L'interruzione "fantasma" e la crescita esponenziale del tempo medio di risoluzione (MTTR)
A differenza di un overflow standard del buffer che attiva un errore SIGSEGV (Clean Segmentation Fault) e genera un crash dump, un conflitto di blocco della memoria heap provoca l'arresto del processo. Il processo non viene terminato, ma interrompe l'elaborazione delle richieste. Il monitoraggio del tempo di attività standard potrebbe mostrare il processo come "in corso", ritardando la risposta all'incidente. Quando i tecnici esaminano il problema, la mancanza dei registri di arresto anomalo complica notevolmente l'analisi delle cause principali, aumentando drasticamente l'MTTR.
L'illusione del "green dashboard"
Questo file binario è firmato digitalmente e utilizza sistemi di protezione della memoria moderni, come, ad esempio, il PIE (Position Independent Executable). In un dashboard standard per la conformità o in una scansione di base delle vulnerabilità, questa risorsa potrebbe apparire sicura. Questa vulnerabilità mette in evidenza il pericolo di affidarsi esclusivamente ai sistemi di mitigazione della piattaforma di base. Il rafforzamento a livello del sistema operativo non è in grado di proteggere da gravi vulnerabilità della logica dell'architettura, che comportano una violazione della simultaneità POSIX.
Il debito tecnologico legacy come leva per lo sfruttamento
I team addetti alla sicurezza delle informazioni spesso accettano il rischio legato ai protocolli legacy (come TLS 1.0), supponendo che "nessuno li stia utilizzando" o che "si tratta solo di un rischio per la decrittografia MITM (Machine-In-The-Middle)". Questa ricerca mostra come il debito tecnologico esistente può essere attivamente sfruttato per sferrare attacchi completamente diversi. La vecchia implementazione TLS non è solo una crittografia debole, ma è l'esatta leva di cui un criminale ha bisogno per ampliare l'intervallo della race condition e sferrare un attacco di danneggiamento della memoria.
La moltiplicazione delle minacce all'intelligenza artificiale (democratizzazione degli exploit complessi)
In passato, individuare e concatenare una violazione della concorrenza POSIX con un declassamento della crittografia legacy per ottenere una desincronizzazione della macchina a stati era un'impresa riservata ai ricercatori d'élite nel campo delle vulnerabilità. Oggi, l'aumento esponenziale di strumenti di AI offensivi e di tecniche di reverse engineering basate sui modelli LLM ha drasticamente ridotto questo ostacolo all'accesso.
Ora, i criminali possono automatizzare l'individuazione di queste oscure intersezioni architettoniche su larga scala. Poiché per i criminali diminuisce la complessità cognitiva necessaria per rilevare e sfruttare queste vulnerabilità, il rischio aziendale di lasciare vulnerabilità della logica multifase senza patch aumenta in modo esponenziale.
Strategie di mitigazione
Per neutralizzare questa complessa catena di exploit, la soluzione deve risolvere sia la causa principale a livello di codice che l'elemento trainante dell'architettura effettuando le seguenti operazioni:
- Refactoring di handler non sicuri
- Eliminazione dei protocolli legacy sull'edge
- Aggiornamento ad avanzate sonde di liveness
- Evoluzione verso l'approccio CTEM e la convalida dell'intelligenza artificiale
Refactoring di handler non sicuri (causa principale)
Gli sviluppatori devono rimuovere rigorosamente le funzioni async-signal-unsafe (free, fprintf) dagli handler dei segnali e affidare alla tecnica di "self-pipe trick" il compito di rinviare in modo sicuro la complessa logica del teardown al ciclo degli eventi dell'applicazione principale.
Eliminazione dei protocolli legacy sull'edge (catalizzatore)
Non affidarti alle configurazioni locali dell'applicazione, ma applica un livello minimo di TLS 1.2+ rigoroso al confine esterno (Web Application Firewall/strumenti di bilanciamento del carico) per impedire ai criminali di sfruttare la manipolazione della latenza necessaria per raggiungere queste race condition microscopiche.
Aggiornamento ad avanzate sonde di liveness (resilienza operativa)
Il monitoraggio del tempo di attività standard non è in grado di rilevare un conflitto di blocco della memoria heap. Pertanto, devi distribuire transazioni sintetiche che verificano attivamente l'allocazione della memoria e lo stato dei processi, garantendo che i processi "fantasma" bloccati siano immediatamente contrassegnati e riavviati.
Evoluzione verso l'approccio CTEM e la convalida dell'intelligenza artificiale (strategia)
I tradizionali test statici sulla sicurezza delle applicazioni (SAST) non consentono di utilizzare queste intersezioni dell'architettura. Pertanto, devi integrare i test dinamici basati sull'intelligenza artificiale nei cicli CTEM (Continuous Threat Exposure Management) per mappare e interrompere in modo proattivo le catene della logica multifase prima che vengano sfruttate dai criminali.
Tag
