Il problema con il sovraccarico del buffer è che un buffer è sovraccarico - questo è privo di senso, cioè è un bug, dopo il quale il comportamento del codice dell'applicazione cessa di seguire il piano pre-ordinato.
Il metodo classico, diciamo primitivo , per sfruttare un overflow del buffer è quello di sovrascrivere lo slot di indirizzo di ritorno di una funzione, in modo che l'esecuzione venga deragliata in una posizione controllata dall'aggressore. Questo funziona solo per i buffer basati su stack e l'industria ha messo a punto varie contromisure per rendere lo sfruttamento più difficile per l'attaccante, ad es. canarini (per rilevare un overflow prima di utilizzare lo slot dell'indirizzo di ritorno) e ASLR (per rendere il salto meno affidabile controllato dall'attaccante).
L'architettura SPARC include register windows , che può essere visualizzato come uno stack dedicato nella CPU, tenuto al di fuori dello spazio di indirizzamento della memoria principale. Pertanto, può essere interpretato il fatto che SPARC sia in qualche modo "immune" al buffer overflow in quanto lo slot dell'indirizzo di ritorno non può essere sovrascritto con un accesso basato sulla memoria. Tuttavia, questo non è vero, per i seguenti motivi:
-
Le finestre di registro sono solo in numero limitato (al massimo 32 nella definizione dell'architettura); quando la profondità della chiamata supera il numero di finestre nella CPU, si verifica un'eccezione e una routine dedicata ne scarica alcune nella RAM, per poi essere ricaricata in un secondo momento. Quindi, le finestre funzionano davvero come una cache sulla RAM; Di conseguenza, in alcuni casi, lo spazio per gli indirizzi di ritorno può ancora essere sovrascritto.
-
C'è più della fessura per l'indirizzo di ritorno nella vita. Fondamentalmente, qualsiasi campo che contenga funzionalmente un puntatore a qualche codice è un buon bersaglio per gli attaccanti. Linguaggi orientati agli oggetti come C ++ sono pieni di tali slot, sia nello stack che nella RAM principale (questi sono chiamati vtables ). Lo slot per l'indirizzo di ritorno è tradizionalmente il principale bersaglio degli attaccanti, perché 20 anni fa era il più facile da raggiungere. (Un famoso exploit che ha sfruttato tali puntatori a funzione non stack dopo un buffer overflow era il PS3 Jailbreak .)
-
Qualsiasi sovrascrittura di dati può essere utile per l'aggressore; anche se iniettare il proprio codice gli dà il massimo potere, altri tipi di overflow possono comunque portare allo sfruttamento di successo. Pensa, per esempio, al bug di cuore che è stato di gran moda pochi mesi fa; ha fatto sì che migliaia di amministratori di sistema e i cosiddetti esperti di sicurezza urlino e corrano in preda al panico ("come i polli senza testa", come si dice da queste parti); eppure era solo un overflow read , in cui nulla è stato sovrascritto.
Un punto cruciale è che tutti questi canarini e ASLR e le finestre di registro sono solo modi per cercare di affrontare le conseguenze dell'eccedenza. L'applicazione è ancora deragliata ei dati sono stati comunque danneggiati. Sarebbe molto meglio agire un po 'prima e impedire che si verifichi l'overflow. Idealmente con un'analisi rigorosa in fase di compilazione (possibilmente con l'aiuto del compilatore), o almeno bloccando il tentativo di overflow in fase di runtime, trasformandolo in qualche eccezione: l'applicazione smette di funzionare correttamente, ma almeno lo fa in modo pulito, senza accanirsi ciecamente con strutture di memoria danneggiate.
Quindi, per difendersi dagli overflow del buffer, l'interessante tecnologia acquisita (e quindi uccisa) da Oracle non è SPARC, ma Java.