Perché i programmi scritti in C e C ++ sono così spesso vulnerabili agli attacchi di overflow?

Question

view on stackexchange narkive permalink

Quando guardo gli exploit degli ultimi anni relativi alle implementazioni, vedo che molti di essi provengono da C o C ++ e molti di loro sono attacchi di overflow.

• Heartbleed era un buffer overflow in OpenSSL;
• Recentemente, è stato scoperto un bug in glibc che consentiva il buffer overflow durante la risoluzione DNS;

sono solo quelli che posso pensare off in questo momento, ma dubito che questi siano gli unici che A) sono per software scritto in C o C ++ e B) sono basati su un buffer overflow.

Soprattutto riguardo al bug glibc, ho letto un commento che afferma che se ciò fosse accaduto in JavaScript invece che in C, non ci sarebbe stato un problema. Anche se il codice fosse stato compilato in Javascript, non sarebbe stato un problema.

Perché C e C ++ sono così vulnerabili agli attacchi di overflow?

Answer 1

view on stackexchange narkive permalink

C e C ++, contrariamente alla maggior parte degli altri linguaggi, tradizionalmente non controllano gli overflow. Se il codice sorgente dice di mettere 120 byte in un buffer di 85 byte, la CPU lo farà felicemente. Ciò è correlato al fatto che mentre C e C ++ hanno una nozione di array , questa nozione è solo in fase di compilazione. In fase di esecuzione, ci sono solo puntatori, quindi non esiste un metodo runtime per verificare l'accesso a un array per quanto riguarda la lunghezza concettuale di tale array.

Al contrario, la maggior parte degli altri linguaggi ha una nozione di array che sopravvive a runtime, in modo che tutti gli accessi agli array possano essere sistematicamente controllati dal sistema runtime. Ciò non elimina gli overflow: se il codice sorgente richiede qualcosa di insensato come scrivere 120 byte in un array di lunghezza 85, non ha ancora senso. Tuttavia, questo attiva automaticamente una condizione di errore interno (spesso una "eccezione", ad esempio un ArrayIndexOutOfBoundException in Java) che interrompe la normale esecuzione e non lascia che il codice proceda. Questo interrompe l'esecuzione e spesso implica la cessazione dell'elaborazione completa (il thread muore), ma normalmente impedisce lo sfruttamento oltre un semplice denial-of-service.

Fondamentalmente, gli exploit del buffer overflow richiedono che il codice l'overflow (leggere o scrivere oltre i limiti del buffer a cui si accede) e per continuare a fare cose oltre tale overflow. La maggior parte dei linguaggi moderni, contrariamente a C e C ++ (e pochi altri come Forth o Assembly), non consente che l'overflow si verifichi davvero e invece spara all'autore del reato. Da un punto di vista della sicurezza questo è molto meglio.

Answer 2

view on stackexchange narkive permalink

Nota che è coinvolto un certo numero di ragionamenti circolari: i problemi di sicurezza sono spesso collegati a C e C ++. Ma quanto di questo è dovuto alle debolezze intrinseche di questi linguaggi, e quanto è dovuto al fatto che quelli sono semplicemente i linguaggi in cui è scritta la maggior parte dell'infrastruttura informatica?

---

C è inteso per essere "un passo avanti rispetto all'assembler". Non ci sono limiti che controllano oltre a quello che hai implementato, per spremere l'ultimo ciclo di clock dal tuo sistema.

C ++ offre vari miglioramenti rispetto a C, il più rilevante per la sicurezza sono le sue classi contenitore (ad esempio <vector> e <string> ) e dal C ++ 11, puntatori intelligenti, che consentono di gestire i dati senza dover gestire manualmente anche la memoria. Tuttavia, essendo un ' evoluzione di C invece di un linguaggio completamente nuovo, fornisce ancora anche la meccanica di gestione manuale della memoria di C, quindi se insisti a spararti in il piede, il C ++ non fa nulla per impedirti di farlo.

---

Allora perché cose come SSL, bind o kernel del sistema operativo sono ancora scritte in questi linguaggi?

Perché questi linguaggi possono modificare la memoria direttamente, il che le rende particolarmente adatte per un certo tipo di applicazioni ad alte prestazioni e di basso livello (come crittografia, ricerche di tabelle DNS, driver hardware ... o Java VM, se è per questo ;-)).

Quindi, se un software rilevante per la sicurezza viene violato, la possibilità che venga scritto in C o C ++ è alta, semplicemente perché la maggior parte del software rilevante per la sicurezza è scritto in C o C ++, solitamente per motivi storici e / o di prestazioni. Se è scritto in C / C ++, il vettore di attacco principale è il sovraccarico del buffer.

Se è se fosse una lingua diversa, sarebbe un diverso attacco vecto r, ma sono sicuro che ci sarebbero anche violazioni della sicurezza.

---

Sfruttare il software C / C ++ è più facile che sfruttare, ad esempio, il software Java. Allo stesso modo in cui sfruttare un sistema Windows è più facile che sfruttare un sistema Linux: il primo è onnipresente, ben compreso (cioè noti vettori di attacco, come trovarli e come sfruttarli), e un molte persone cercano exploit in cui il rapporto ricompensa / impegno è alto.

Ciò non significa che quest'ultimo sia intrinsecamente sicuro (più sicuro er , forse, ma non sicuro ). Significa che, essendo l'obiettivo più difficile con minori benefici, i Bad Boys non ci stanno ancora perdendo molto tempo.

Answer 3

view on stackexchange narkive permalink

In realtà, "heartbleed" non era proprio un buffer overflow. Per rendere le cose più "efficienti", mettono molti buffer più piccoli in un unico grande buffer. Il grande buffer conteneva dati da vari client. Il bug leggeva byte che non avrebbe dovuto leggere, ma in realtà non leggeva dati al di fuori di quel grande buffer. Un linguaggio che controllava i buffer overflow non lo avrebbe impedito, perché qualcuno si è fatto in quattro o ha impedito a tali controlli di trovare il problema.

Answer 4

view on stackexchange narkive permalink

In primo luogo, come altri hanno già detto, C / C ++ è talvolta caratterizzato come un glorificato macro assembler: è pensato per essere "vicino al ferro", come linguaggio per la programmazione a livello di sistema.

Quindi, ad esempio, il linguaggio mi consente di dichiarare un array di lunghezza zero come segnaposto quando, in realtà, può rappresentare una sezione di lunghezza variabile in un pacchetto di dati o l'inizio di una regione di lunghezza variabile nella memoria che viene utilizzata per comunicare con un componente hardware.

Sfortunatamente significa anche che C / C ++ è pericoloso nelle mani sbagliate; se un programmatore dichiara un array di 10 elementi e poi scrive nell'elemento 101, il compilatore lo compilerà felicemente, il codice verrà eseguito felicemente, eliminando qualunque cosa accada in quella posizione di memoria (codice, dati, stack, chi lo sa.)

In secondo luogo, C / C ++ è idiosincratico. Un buon esempio sono le stringhe, che sono fondamentalmente array di caratteri. Ma ogni costante di stringa porta un carattere di terminazione invisibile aggiuntivo. Questa è stata la causa di innumerevoli errori in quanto (soprattutto, ma non esclusivamente) i programmatori inesperti spesso non riescono ad allocare quel byte aggiuntivo necessario per il null di terminazione.

Terzo, C / C ++ è in realtà piuttosto vecchio. Il linguaggio è nato in un momento in cui gli attacchi esterni a un sistema software erano praticamente inesistenti. Gli utenti dovevano essere affidabili e collaborativi, non ostili, poiché il loro obiettivo era far funzionare il programma, non bloccarlo.

Ecco perché la libreria C / C ++ standard contiene molte funzioni che sono intrinsecamente non sicure. Prendi strcpy (), per esempio. Copierà felicemente qualsiasi cosa fino a quando un carattere nullo terminante. Se non trova un carattere nullo di terminazione, continuerà a copiare finché l'inferno non si congela, o più probabilmente, finché non sovrascrive qualcosa di vitale e il programma si blocca. Questo non era un problema ai bei vecchi tempi, quando non ci si aspettava che un utente entrasse in un campo riservato, ad esempio, a un codice postale, 16000 caratteri spazzatura seguiti da un insieme di byte appositamente costruito che dovevano essere eseguiti dopo che lo stack è stato eliminato e il processore ha ripreso l'esecuzione all'indirizzo sbagliato.

Giusto per essere sicuri, C / C ++ non è l'unico linguaggio idiosincratico là fuori. Altri sistemi hanno un comportamento idiosincratico diverso, ma può essere altrettanto negativo. Prendi i linguaggi di programmazione back-end come PHP e quanto è facile scrivere codice che consenta l'iniezione SQL.

Alla fine, se diamo ai programmatori i potenti strumenti di cui hanno bisogno per fare il loro lavoro, ma senza una formazione adeguata e consapevolezza dell'ambiente di sicurezza, le cose brutte accadranno indipendentemente dal linguaggio di programmazione utilizzato.

Answer 5

view on stackexchange narkive permalink

Probabilmente toccherò alcune cose che alcune delle altre risposte hanno già affermato .. ma .. trovo che la domanda stessa sia errata e "vulnerabile".

Come chiesto, la domanda è per scontata molto senza capire i problemi di fondo. C / C ++ non sono "più vulnerabili" di altri linguaggi. Piuttosto, affidano la maggior parte della potenza dei dispositivi informatici e la responsabilità dell'uso di tale potenza direttamente nelle mani del programmatore. Quindi, la realtà della situazione è che molti programmatori scrivono codice che è vulnerabile allo sfruttamento e poiché C / C ++ non fa di tutto per proteggere il programmatore da se stesso come fanno alcuni linguaggi, il loro codice è più vulnerabile. Questo non è un problema C / C ++, poiché i programmi scritti in linguaggio assembly avrebbero gli stessi problemi, ad esempio.

Il motivo per cui una programmazione di basso livello può essere così vulnerabile è perché fare cose come il controllo dei limiti di array / buffer può diventare costoso in termini di calcolo e molto spesso non è necessario quando si programma in modo difensivo. Immagina, ad esempio, di scrivere codice per un importante motore di ricerca, che deve elaborare trilioni di record di database in un batter d'occhio, in modo che l'utente finale non si annoi o non si annoi durante il "caricamento della pagina ..." È visualizzato. Non si desidera che il codice continui a controllare i limiti di array / buffer ogni singola volta nel ciclo; Sebbene possano essere necessari nanosecondi per eseguire tale controllo, il che è banale se stai elaborando solo dieci record, può aggiungere fino a molti secondi o minuti quando esegui il ciclo di miliardi o trilioni di record.

Quindi, invece, "ti fidi" che l'origine dati (ad esempio, il "web bot" che analizza i siti web e inserisce i dati nel database) abbia già controllato i dati. Questo non dovrebbe essere un presupposto irragionevole; Per un programma tipico, vuoi controllare i dati in input , in modo che il codice che elabora i dati possa funzionare alla massima velocità. Anche molte librerie di codice adottano questo approccio. Alcuni documentano addirittura che si aspettano che il programmatore abbia già controllato i dati prima di chiamare le funzioni di libreria per agire sui dati.

Sfortunatamente, tuttavia, molti programmatori non programmano in modo difensivo e presumono semplicemente che i dati debbano essere valido e entro limiti / parametri sicuri. E questo è ciò che viene sfruttato dagli aggressori.

Alcuni linguaggi di programmazione sono progettati in modo tale da cercare di proteggere il programmatore da pratiche di programmazione così scadenti inserendo automaticamente controlli aggiuntivi nel programma generato, cosa che il programmatore non ha fatto scrivere esplicitamente nel loro codice. Ancora una volta, questo va bene quando eseguirai il ciclo del codice solo poche centinaia di volte o meno. Ma quando stai attraversando miliardi o trilioni di iterazioni, si verificano lunghi ritardi nell'elaborazione dei dati, che potrebbero diventare inaccettabili. Quindi è un compromesso quando si sceglie quale lingua utilizzare per un particolare pezzo di codice e quanto spesso e dove si verificano condizioni potenzialmente pericolose / sfruttabili all'interno dei dati.

Answer 6

view on stackexchange narkive permalink

Fondamentalmente i programmatori sono persone pigre (me compreso). Fanno cose come usare gets () invece di fgets () e definire i buffer di i / o sullo stack e non cercare abbastanza i modi in cui la memoria potrebbe essere sovrascritta involontariamente (beh, involontariamente per il programmatore, intenzionalmente per l'hacker :).

Answer 7

view on stackexchange narkive permalink

Esiste una grande quantità di codice C esistente che esegue la scrittura non controllata nei buffer. Alcuni di questi sono nelle biblioteche. Questo codice è potenzialmente pericoloso se uno stato esterno può cambiare la lunghezza scritta, e solo molto pericoloso altrimenti.

C'è una quantità maggiore di codice C esistente che esegue la scrittura limitata nei buffer. Se l'utente di detto codice commette un errore di matematica e lascia che sia scritto più di quanto dovrebbe, questo è sfruttabile come sopra. Non vi è alcuna garanzia in fase di compilazione che i calcoli siano eseguiti correttamente.

C'è anche una grande quantità di codice C esistente che legge in base agli offset in memoria. Se l'offset non viene verificato come valido, ciò può far perdere informazioni.

Il codice C ++ viene spesso utilizzato come linguaggio di alto livello per l'interoperabilità con C, quindi vengono seguite molte idee di C e bug dalla comunicazione con C Le API sono comuni.

Esistono stili di programmazione C ++ che impediscono tali sovraccarichi, ma basta un solo errore per consentirli.

Inoltre, il problema dei puntatori penzolanti, dove la memoria le risorse vengono riciclate e il puntatore ora punta alla memoria con una durata / struttura diversa da quella originaria, consente alcuni tipi di exploit e fughe di informazioni.

Questi tipi di errori - errori "fencepost", "penzoloni gli errori "pointer" - sono così comuni, e così difficili da eliminare completamente, che molti linguaggi sono stati sviluppati con sistemi progettati esplicitamente per impedire che si verifichino.

Non sorprende che nei linguaggi progettato per eliminare questi errori, questi errori non si verificano così spesso. A volte si verificano ancora: o il motore che esegue il linguaggio ha il problema, o viene impostata una situazione manuale che corrisponde all'ambiente del caso C / C ++ (riutilizzo di oggetti in un pool, utilizzando comune un grande buffer comune suddiviso per consumatore, ecc. ). Ma poiché questi usi sono più rari, il problema si verifica meno spesso.

Ogni allocazione dinamica, ogni utilizzo del buffer, in C / C ++ corre questi rischi. Ed essere perfetti non è raggiungibile.

Answer 8

view on stackexchange narkive permalink

I linguaggi più comunemente usati (Java e Ruby, ad esempio) vengono compilati in codice che viene eseguito in una VM. La VM è progettata per separare il codice macchina, i dati e solitamente lo stack. Ciò significa che le normali operazioni del linguaggio non possono modificare il codice o reindirizzare il flusso di controllo (a volte ci sono API speciali che possono farlo, ad esempio per il debug).

C e C ++ vengono solitamente compilati direttamente nel linguaggio macchina nativo della CPU: questo offre vantaggi in termini di prestazioni e flessibilità, ma significa che un codice errato può sovrascrivere la memoria del programma o lo stack e quindi eseguire istruzioni non nel programma originale.

Ciò si verifica in genere quando un buffer viene sovraccaricato (forse deliberatamente) in C ++. In Java o Ruby, al contrario, un sovraccarico del buffer causerà immediatamente un'eccezione e non può (ad eccezione dei bug della VM) sovrascrivere il codice o modificare il flusso di controllo.