Distruggi lo stack se cresce verso l'alto

Gli overflow del buffer si verificano a causa di un bug di programmazione: a causa di circostanze impreviste dello sviluppatore, ma attivate dall'attaccante, il codice sta scrivendo dati oltre la fine del buffer. Che fine? Bene, ci sono due : verso indirizzi alti e verso indirizzi bassi.

Il modo tradizionale per scrivere un ciclo è il seguente:

for (i = 0; i < n; i ++)

e non in questo modo:

for (i = n - 1; i >= 0; i --)

che significa che gli sviluppatori tendono ad applicare algoritmi nell'ordine basso-alto. Non c'è una ragione matematica per questo, ma gli sviluppatori sono addestrati a pensare in questo modo; e l'evoluzione dell'hardware è seguita (le strategie di pre-recupero dei chip RAM si basano anche su questo modello). I soliti sospetti per la manipolazione delle stringhe ( strcat() , sprintf() ...) hanno anche un overflow sull'estremità alta per lo stesso motivo: operano da basso a alto.

Ciò implica che la maggior parte degli overflow del buffer si verificano anche nella parte alta del buffer, non nella fascia bassa. Su uno stack che cresce verso il basso, questo permette a questi overflow di indirizzare l'indirizzo di ritorno della funzione corrente: il migliore che un exploit di overflow del buffer possa sperare stia reindirizzando l'esecuzione nel codice scelto dall'attaccante, e per questo l'overflow sovrascriverà uno slot di memoria che contiene un puntatore al codice, che il codice seguirà in un altro punto. Lo slot "indirizzo di ritorno" nello stack è conveniente. Ma non è l'unico puntatore al codice.

In particolare, quando si utilizza C ++, qualsiasi oggetto con metodi virtuali deve contenere un qualche tipo di riferimento a una struttura contenente un puntatore a questi metodi (il vtable ). Questo fornisce molti altri bersagli extra che possono trovarsi nel raggio d'azione di un buffer overflow. Gli oggetti C ++ possono essere allocati allo stack.

Un altro punto è che quando un buffer viene sorvolato, potrebbe trovarsi in un altro stack frame. Ad esempio, questo:

void foo(char *s)
{
    char buf[10];
    bar(buf, "x", s);
}

void bar(char *dst, char *s1, char *s2)
{
    sprintf(dst, "%s/%s", s1, s2);
}

In questo esempio, se l'autore dell'attacco può inserire una stringa sovradimensionata come parametro su foo() , il buffer allocato sul frame dello stack per foo() verrà overflow in bar() . Se lo stack cresce verso l'alto, l'indirizzo di ritorno per foo() non sarà danneggiato, ma quello per bar() verrà sovrascritto.

Per riassumere:

• Uno stack crescente verso l'alto significa che l'indirizzo di ritorno della funzione della funzione che ha assegnato il buffer di solito non dovrebbe essere illesi.
• Ma gli altri slot di indirizzo di ritorno funzione per altre funzioni potrebbero essere nel raggio d'azione (e in realtà essere più nel raggio d'azione che se lo stack fosse cresciuto verso il basso).
• E anche se sono più rari, i buffer overflow nella fascia bassa (a volte chiamati "underflow") si verificano anche nella pratica.
• E lo slot dell'indirizzo di ritorno è solo uno degli obiettivi succosi di un utente malintenzionato.

Quindi non possiamo davvero pensare a pile in crescita come una protezione contro lo sfruttamento dei buffer overflow. Cambia le condizioni di attacco, ma non necessariamente verso motivi più sicuri. L'esperienza mostra che i buffer overflow sono stati sfruttati con successo su architetture con stack in crescita.

(Nota: la PA-RISC CPU , di per sé, non conosce stack. Lo stack fa parte della convenzione di chiamata , che dice che GR 30 deve essere usato convenzionalmente come puntatore dello stack e che lo stack cresca verso l'alto. come HP definito ma qualsiasi sistema operativo potrebbe decidere diversamente.È una tendenza generica per la maggior parte della CPU RISC: l'hardware non conosce stack, quindi la posizione e la direzione dello stack sono una questione di convenzione tra sistema operativo e applicazioni.)

Sì, i buffer overflow esistono su architetture RISC come MIPS e PA-RISC. La rivista Phrack ha pubblicato un articolo sul buffer PA-RISC traboccante circa 12 anni fa nell'articolo 58, ma probabilmente lo sapresti già se sapessi come interrogare Google.

Devo ammettere che non sono esperto in materia di PA-RISC, ma ne ho una comprensione di base. Perciò piuttosto che me parafrasando l'articolo di frase, ti suggerisco di leggerlo per te stesso.