È stato identificato una vulnerabilità nel gestore di pacchetti APT (CVE-2019-3462), di consente a un utente malintenzionato di avviare uno spoofing del pacchetto installato se l'autore dell'attacco ha il controllo del mirror del repository o può interrompere il traffico di transito tra l'utente e il repository (attacco MITM).
Il problema è stato identificato dal ricercatore di sicurezza Max Justicz, noto per il rilevamento delle vulnerabilità nel gestore di pacchetti APK (Alpine) e nei repository Packagist, NPM e RubyGems.
Il problema È dovuto a una verifica errata dei campi nel codice di elaborazione del reindirizzamento HTTP.
Qual è il problema?
Questa vulnerabilità consente a un utente malintenzionato di sostituire il proprio contenuto nei dati trasmessi all'interno della sessione HTTP (Debian e Ubuntu utilizzano HTTP e non HTTPS per accedere al repository, supponendo che la firma digitale sia sufficiente con metadati e dimensioni del pacchetto corrispondenti.)
La vulnerabilità identificata consente il potere dell'attaccante sostituire il pacchetto trasmesso, dopodiché APT lo percepirà come ricevuto dal mirror ufficiale e avvierà il processo di installazione.
Attraverso l'inclusione nel pacchetto dannoso di script lanciati durante l'installazione, un malintenzionato può ottenere l'esecuzione del proprio codice su un sistema con privilegi di root.
Per scaricare i dati dal repository, APT avvia un processo figlio con l'implementazione di un trasporto specifico e organizza l'interazione con questo processo utilizzando un semplice protocollo di testo con la divisione dei comandi per una riga vuota.
Come rilevo il problema?
L'essenza del problema è che il gestore di trasporto HTTP, dopo aver ricevuto una risposta dal server HTTP con l'intestazione "Location:", richiede la conferma del reindirizzamento dal processo principale.
Trasferimento completo del contenuto di questa intestazione. A causa della mancanza di pulizia dei caratteri speciali trasmessi, un utente malintenzionato può specificare un'interruzione di riga nel campo "Posizione:".
Poiché questo valore verrà decodificato e trasmesso attraverso il canale di comunicazione con il processo principale, l'attaccante può simulare una risposta diversa dal gestore di trasporto HTTP e sostituire il blocco URI 201 fittizio.
Ad esempio, se, durante la richiesta di un pacchetto, l'attaccante sostituisce la risposta, questa sostituzione comporterà il trasferimento del successivo blocco di dati al processo principale.
Il calcolo degli hash per i file scaricati viene gestito e il processo principale controlla semplicemente questi dati con gli hash dal database dei pacchetti firmati.
Tra i metadati, un utente malintenzionato può specificare qualsiasi valore di hash di test collegati nel database ai pacchetti firmati effettivi, ma in realtà non corrisponde agli hash del file trasferito.
Il processo principale accetterà il codice di risposta sostituito dall'attacco, cercherà l'hash nel database e considererà che viene caricato il pacchetto per il quale è presente una firma digitale corretta, sebbene in realtà il valore del campo con l'hash venga sostituito in il canale di comunicazione con il processo principale che utilizza l'attacco e il file specificato nei metadati sostituiti.
Il download di un pacchetto dannoso viene eseguito allegando il pacchetto al file Release.gpg, durante il trasferimento.
Questo file ha una posizione prevedibile sul file system e allegare un pacchetto al suo avvio non influisce sull'estrazione della firma digitale dal repository.
Quando si ottengono i dati, apt disabilita i processi di lavoro specializzati nei vari protocolli che verranno utilizzati per il trasferimento dei dati.
Il processo principale quindi comunica con questi lavoratori tramite stdin / stdout per dire loro cosa scaricare e dove metterlo nel filesystem utilizzando un protocollo che assomiglia un po 'a HTTP.
Il processo principale invierà quindi la sua configurazione e richiederà una risorsa e il processo di lavoro risponderà.
Quando il server HTTP risponde con un reindirizzamento, il processo di lavoro restituisce un reindirizzamento a 103 invece di un URI 201 Fatto, e il processo principale utilizza questa risposta per capire quale risorsa richiedere successivamente.