Come promesso torno sulla CVE con gli esiti dei test che ho fatto: mi ero ripromesso di dedicarci una paio di sessioni e così ho fatto.
Rimanendo praticamente sullo stesso “impianto” di laboratorio presentato nella prima parte ho fatto diverse prove di formattazione di una risposta ICMP il cui contenuto fosse modificato. In particolare ho mantenuto la linea della risposta “Destination Unreachable” inizialmente modificando il payload nella risposta e successivamente formattando una risposta “pulita” ma inserendo nel messaggio di origine un contenuto arbitrario (la solita stringa “AAAA…”).
Per l’invio del ping “modificato” ho utilizzato il seguente comando:
-- ping -c 1 -s 1016 -p "41414141" 1.3.3.7Non ho ottenuto particolari risultati con scapy ne con l’opzione -p di ping: la risposta veniva correttamente inviata alla macchina FreeBSD e la funzione pr_pack() veniva effettivamente chiamata, ma non sono riuscito ad ottenere comportamenti anomali.
A differenza di quanto ottenuto in un altri contesti (rif. al mio precedente post) la dimensione di hlen in questo scenario resta di 20 bytes. Evidentemente, nonostante l’errore generato mi sembri corretto, non si verificano le condizioni per cui il programma va a ricostruire il pacchetto utilizzando i dati “raw” del pacchetto che ha generato l’errore.
Nel frattempo mi sono ricordato di un check che avrei duvoto fare all’inizio del test: ho appurato che di default ping.c viene compilato con le opzioni di protezione dello stack attive, ne possiamo desumere che la sfruttabilità dell’overflow è quindi molto bassa.
Una ultima prova che potrebbe aver senso fare (lo ho scritto poco fa anche sul canale telegram) è tentare un fuzzing con scapy, ovviamente dopo aver ricompilato ping.c con le protezioni dello stack disabilitate.
Io mi fermo qui 😉
Rocco Sicilia 