In questo articolo Indice dei contenuti 2 sezioni
Una vulnerabilità scoperta in LibreOffice Calc consente a un foglio di calcolo costruito ad hoc di caricare ed eseguire codice Java remoto sfruttando un driver JDBC, il tutto senza che compaia il classico avviso legato alle macro. Il problema non nasce da un singolo errore ma dall’incontro di più funzioni perfettamente legittime del programma che, messe insieme, trasformano un documento all’apparenza innocuo in un possibile veicolo di attacco. La Document Foundation ha già sistemato la falla nelle versioni 26.2.5 e 26.8.0, mentre Apache OpenOffice soffre di un difetto analogo che attende ancora una soluzione definitiva.
Il caso merita attenzione perché mostra in modo piuttosto chiaro come si possa aggirare l’intero modello di sicurezza pensato attorno alle macro, cioè proprio quello che di solito mette in guardia chi apre un file sospetto.
Il percorso che porta dal foglio al codice remoto
Tutto comincia da una funzione di Calc chiamata database range, che serve a collegare un intervallo di celle a una sorgente dati esterna e ad aggiornarne il contenuto. Un documento può puntare a una risorsa ODB, ovvero un file di database di LibreOffice, tramite un indirizzo remoto. All’apertura del foglio Calc può andare a recuperare quella risorsa per rinfrescare i dati collegati.
Il punto cruciale però si trova dentro il file ODB. Qui è possibile indicare un driver JDBC, sigla di Java Database Connectivity, lo strumento con cui le applicazioni Java dialogano con sistemi di database diversi. Nello scenario studiato dai ricercatori la configurazione può specificare anche dove si trova il codice del driver, indicando una posizione remota. A quel punto Calc scarica un archivio JAR con dentro il codice Java e lo inizializza all’interno del processo stesso dell’applicazione. A creare le condizioni per eseguire codice controllato da chi attacca è quindi questa catena di passaggi, non il semplice uso di JDBC.
Ed è qui che la differenza rispetto alle macro diventa evidente. Le macro rappresentano un meccanismo dichiaratamente associato all’esecuzione di codice presente nei documenti e normalmente LibreOffice può chiedere un’autorizzazione prima di avviarle. In questo caso il codice entra invece attraverso il caricamento di un driver richiesto dalla configurazione della sorgente dati. Chi apre il file non vede quindi nessun messaggio capace di far scattare un campanello d’allarme. Per dimostrarlo i ricercatori hanno preparato una prova pratica che si limita ad avviare la calcolatrice di sistema, usata come esempio del tutto innocuo dell’avvenuta esecuzione.
Perché l’attacco vada a segno serve comunque che il supporto Java sia presente e attivo nella suite. Questo requisito restringe le situazioni in cui la falla è sfruttabile e offre anche un rimedio immediato a chi non ha bisogno delle funzioni Java. Disattivando l’integrazione con Java il percorso usato dalla vulnerabilità non riesce ad arrivare all’inizializzazione del codice remoto.
LibreOffice già aggiornato, OpenOffice ancora in attesa
Su LibreOffice la correzione introduce un limite al percorso delle classi Java. Nelle versioni aggiornate le voci devono essere espresse come file URL, così il documento non può più indicare direttamente una posizione remota da cui caricare le classi. La Document Foundation consiglia quindi di passare almeno a una delle release corrette già disponibili.
Per Apache OpenOffice la situazione è diversa. Risultano coinvolte tutte le versioni fino alla 4.1.16, mentre la correzione arriverà con la 4.1.17, ancora in preparazione. Nel frattempo il progetto suggerisce come misura temporanea di disattivare il runtime Java dalle impostazioni del programma.
Le due vulnerabilità sono state individuate in modo indipendente da Rick de Jager del team V12 e da Thomas Rinsma ed Edoardo Geraci di Codean Labs. La patch di LibreOffice porta la firma di Caolán McNamara di Collabora Productivity. Al momento della divulgazione non risultavano attacchi reali documentati.
Fonte: TecnoAndroid
