Qual è lo sfondo dell'overflow del contatore di riferimento in Microsoft TCP / IP (MS11-083)?

Le informazioni personali di Microsoft sono abbastanza descrittive per questo problema. È una vulnerabilità di overflow del contatore di riferimento. In termini molto semplici, immagina di avere un pezzo di codice come questo:

size_t num_of_connections = 0;

È così che tieni traccia del numero di connessioni, ma devi anche fare i conti con il fatto che size_t ha una dimensione limitata. Se continui ad aggiungere 1 a size_t alla fine, "supererai" il valore intero. Quello che succede a quel punto dipende dal segno dei dati.

Dì per un minuto che tutti i registri sono a 4 bit. Questo non è vero per il tuo PC, ma mantiene i numeri funzionanti! Quindi il valore massimo senza segno che possiamo tenere in un singolo registro sarebbe 1111 = 15 . Supponiamo di fare 15+1 . La risposta è 10000 = 16 ma non può rientrare nel nostro registro a 4 bit. Ci sono due cose che potrebbero accadere. Se utilizzi un'istruzioneadd x86% standard, quella percentuale extra di1 cade semplicemente nell'abisso, per non essere più vista. Quindi il risultato in base al tuo programma sarebbe 15+1 = 0 . Se stai utilizzando adc , il risultato è lo stesso, ma il flag carry sarà impostato e il prossimo adc aggiungerebbe anche 1 al risultato. Per motivi di interesse, C non usa adc o usa il flag carry.

Ora, l'altra alternativa è che stiamo usando un valore firmato. In questo caso il valore positivo massimo è 0111 = 7 e il valore negativo massimo è 1111 = 8 (utilizzando il complemento a due). Se ne aggiungi uno a sette, eccederai ancora, quindi 0111+1 = 1000 che implica 7+1 =-8 .

Il problema non è che ciò accada - è che si fa un'ipotesi nel codice in base all'insieme di valori che possono apparire e quindi non si gestisce il caso di un overflow (e naturalmente che un overflow non causerà alcun eccezione o errore a tutti - succede solo). La sottrazione può anche essere un problema, in cui si passa da piccoli valori a un valore elevato perché si è "sorvolato" nell'altro modo. Potresti trovare articolo della frase sull'argomento come una lettura piuttosto interessante.

Quindi, per rispondere alla tua domanda, mentre non conosco le specifiche, sospetto che il bug sia il risultato di qualsiasi vecchio pacchetto inviato mi permetta di chiarire che prima di un'esplosione scoppia nei commenti sottostanti ... il bug sarà probabilmente causato da eventuali vecchi pacchetti inviati, ma probabilmente causerà un crash. Per sfruttarlo veramente è necessario un modo per ottenere il carico utile in-i.e. controllare ciò che accade con l'arresto anomalo. È qui che sceglie con cura i tuoi pacchetti (grazie Hendrik, +1); abbastanza da far traboccare qualsiasi contatore di ref viene utilizzato qui. È una vulnerabilità unica? Non proprio - è un problema noto. Non è un bug in TCP, dal momento che UDP e TCP sono cose diverse. È un bug nella gestione dei pacchetti UDP nello stack TCP / UDP di Microsoft. Gestire le porte su cui i servizi non sono in ascolto è ancora una potenziale area di rischio per la sicurezza - dal momento che il sistema operativo deve respingere correttamente questi pacchetti e gestire eventuali potenziali alluvioni di tali pacchetti.

Per mitigare tali problemi nel tuo codice, il consiglio del CERT -C linee guida sugli interi è utile, in particolare INT03-C .

The vulnerability could allow remote code execution if an attacker sends a continuous flow of specially crafted UDP packets to a closed port on a target system. https://technet.microsoft.com/en-us/security/bulletin/ms11-083

Quindi, anche se un'enorme quantità di pacchetti UDP con tutti i bit impostati su zero potrebbe causare un arresto anomalo, è improbabile che ciò comporterà l'esecuzione di codice. Devono contenere contenuti scritti appositamente per sfruttare il problema.

È un overflow del contatore di riferimento in base alla stessa fonte Microsoft.

Che cos'è un contatore di riferimento?

Quando un programma assegna un blocco di memoria, può essere utilizzato un contatore di riferimento per gestirlo. Ogni volta che una parte del codice del programma vuole accedervi, il contatore viene incrementato. Ogni volta che questa parte di codice viene eseguita con il blocco di memoria, il contatore viene decrementato. Quando il contatore raggiunge 0, nessuno è più interessato al blocco di memoria e viene liberato.

Che cos'è un overflow di numeri interi?

I numeri interi sono numeri usati per il conteggio. Hanno una dimensione fissa nella memoria del computer. Ad esempio 32 bit o 64 bit. Quindi, a differenza degli interi, sai dalla matematica, c'è un numero maggiore possibile. Aggiungendo 1 a quel numero si otterrà un numero molto negativo o 0.

In altre parole, se aggiungi 1 ancora e ancora, finirai con 0.

Che cos'è una vulnerabilità del contatore di riferimento?

Una vulnerabilità del contatore di riferimento è solitamente causata da un percorso del programma che non riesce a decrementare il contatore di riferimento. L'attaccante è quindi in grado di incrementare il contatore ancora e ancora.

Come risultato, può ottenere il contatore a 0 e oltre (vedere la sezione precedente). Dopo aver ottenuto il contatore di overflow e finito nuovamente a 1, attiverà il normale percorso del programma che decrementerà il contatore.

Ora il contatore ha raggiunto 0. 0 significa che nessuno è interessato al blocco di memoria, quindi verrà liberato.

Qual è il percorso di errore in questo contesto?

Il percorso del programma che non riesce a decrementare il contatore viene utilizzato quando non c'è ascolto del servizio sulla porta UDP.

È facile concludere che per il decremento finale è necessaria una porta UDP aperta per sfruttare il problema. Microsoft, tuttavia, non ha menzionato questo. Inoltre hanno dichiarato che Windows Firewall non offre alcuna protezione contro questo bug. Quindi la conclusione è probabilmente sbagliata.

Perché la liberazione della memoria usata blocca una cosa brutta?

Liberare memoria significa semplicemente che è contrassegnato come "disponibile". Qualcun altro, che richiede un blocco di memoria, può quindi ottenerlo. Ma il programma originale pensa ancora, possiede il blocco e può usarlo come vuole.

Quindi finiamo con due programmi che utilizzano lo stesso blocco di memoria senza essere consapevoli l'uno dell'altro. Ciò ovviamente causa incoerenze nei dati.

Con un po 'di sfortuna e abilità speciali, uno di questi programmi può fare cose cattive all'altra. Immagina che l'altro programma stia memorizzando il codice del programma, i puntatori al codice del programma o dati attendibili che determineranno puntatori al codice del programma in questo blocco di memoria.

È un rischio reale?

Sì. Non è facile da sfruttare e si noterà probabilmente l'invio di una quantità così grande di pacchetti UDP su una connessione Internet lenta. Ma è un vero problema che deve essere corretto.