Per favore, aggiungi TurboLab.it alle eccezioni del tuo Ad Blocker. Siamo un progetto no-profit, e la pubblicità è indispensabile per pagare le spese.
In alternativa, puoi sostenerci con una donazione.
Rispetteremo ogni tua scelta, e potrai sempre utilizzare il sito senza limitazioni.
Chi usa TightVNC per fare assistenza remota è abituato a pensare che il rischio stia sulla macchina controllata, non sulla propria. Questa volta è il contrario. In TightVNC Viewer 2.8.88 per Windows a 64 bit è stata scoperta una vulnerabilità di esecuzione di codice da remoto pre-autenticazione: un server VNC malevolo può eseguire codice sul PC del tecnico prima ancora che compaia la richiesta della password. Il componente vulnerabile è il Viewer, cioè proprio lo strumento con cui l'amministratore si collega agli altri sistemi.
La ricerca è firmata da SeongJoon Cho di SSD Labs Korea ed è stata pubblicata da SSD Secure Disclosure, un programma che acquista vulnerabilità dai ricercatori, le segnala ai produttori e ne rende pubblici i dettagli una volta rilasciata la correzione. Insieme all'analisi è arrivato anche un exploit funzionante, tvnexploit.py, che trasforma la corruzione di memoria in esecuzione di codice vera e propria.
TightVNC è un software gratuito di controllo remoto distribuito sotto licenza GPL e sviluppato da GlavSoft, basato sul protocollo VNC. Si compone di due parti: il Server, che gira sul PC controllato, e il Viewer, usato dal tecnico per vedere e comandare la macchina remota. È un'alternativa gratuita a strumenti commerciali come TeamViewer o AnyDesk, usata da help desk, sistemisti e piccoli fornitori IT.
La falla nasce da un errore di troncamento di interi nel calcolo della dimensione del framebuffer. La funzione FrameBuffer::getBufferSize(), in rfb/FrameBuffer.cpp, calcola la dimensione del buffer con aritmetica a 64 bit, ma poi tronca il risultato in un intero a 32 bit. Il calcolo degli offset di scrittura dei pixel, invece, continua a usare le dimensioni originali, senza alcun controllo sui limiti dell'allocazione reale.
L'esempio concreto fornito dai ricercatori è chiaro: un server malevolo dichiara uno schermo da 32.768 × 32.769 pixel a 32 bit per pixel. Servirebbero circa 4 GB di memoria, ma a causa del troncamento a 32 bit il Viewer ne alloca appena 128 kB. Il programma però usa comunque le dimensioni gigantesche per calcolare dove scrivere, creando una discrepanza tra buffer allocato e area logica. Poiché l'offset di scrittura è un intero a 32 bit con segno e non controllato, un valore elevato può andare in overflow e permettere al server di scrivere a un offset arbitrario, positivo o negativo, rispetto al framebuffer.
Il punto chiave è che nel protocollo RFB l'autenticazione è a senso unico: solo il server può sfidare il viewer, mai il contrario. Un server ostile può quindi dichiarare come tipo di sicurezza "None", cioè nessuna autenticazione, e il TightVNC Viewer lo accetta, saltando del tutto la richiesta della password. Lo sfruttamento avviene durante l'avvio della sessione, prima che vengano scambiate le credenziali. Da qui l'etichetta pre-autenticazione.
L'exploit pubblicato da SSD manipola prima la lunghezza di un buffer in uscita per leggere la memoria vicina e aggirare l'ASLR, recuperando gli indirizzi necessari. Poi reindirizza una chiamata a funzione e, tramite ROP, invoca la funzione CreateProcessW di Windows per avviare un processo arbitrario. Il proof of concept è completo e funzionante: la barriera d'ingresso allo sfruttamento si abbassa parecchio.
Gli scenari di attacco sono due. Nella modalità di ascolto, avviando tvnviewer.exe -listen, il Viewer si mette in ascolto su 0.0.0.0:5500, senza restrizioni sull'IP e senza password, in attesa di connessioni in arrivo. È una configurazione comune negli help desk, e in questo caso l'esecuzione di codice da remoto è esposta direttamente sulla rete. Nella connessione in uscita basta invece che il Viewer si colleghi a un indirizzo controllato dall'attaccante, sia esso un link malevolo, un finto server di supporto o un server legittimo la cui porta è stata compromessa. La compromissione scatta all'istante, appena stabilita la connessione.
Da sottolineare: è vulnerabile solo il componente Viewer, non qualsiasi macchina Windows su cui giri un server TightVNC. La disclosure non riporta prove di sfruttamento attivo in rete.
GlavSoft ha corretto la falla in silenzio, senza advisory né CVE, e secondo SSD senza mai rispondere ai ricercatori. Sulla data esatta della correzione le fonti divergono: la versione 2.8.89 risulta rilasciata attorno al 2-3 ottobre 2026, mentre le note ufficiali di TightVNC citano il 2 e il 5 ottobre come date di aggiornamento di sicurezza. In ogni caso sia la 2.8.89 sia la successiva 2.8.90 intervengono su problemi di sicurezza del Viewer, e il produttore raccomanda l'aggiornamento alla versione 2.8.90.
Se usi TightVNC Viewer per l'amministrazione remota, aggiorna subito alla 2.8.90. Nel frattempo, disattiva la modalità di ascolto se non ti serve, limita la porta TCP 5500 ai soli sistemi fidati ed evita di collegare il Viewer a server VNC non verificati. Attenzione però: le restrizioni di rete riducono l'esposizione, ma non sostituiscono la patch sul componente vulnerabile.
Fonti: cryptika.com, pasqualepillitteri.it, ssd-disclosure.com
Nessuno ha ancora commentato.
