Perché è così difficile rendere C meno soggetto a buffer overflow?

Sto facendo un corso al college, dove uno dei laboratori deve eseguire exploit buffer overflow sul codice che ci danno. Questo varia da semplici exploit come la modifica dell'indirizzo di ritorno per una funzione su uno stack per tornare a una funzione diversa, fino al codice che modifica lo stato di un registro / memoria dei programmi ma poi ritorna alla funzione che hai chiamato, il che significa che il la funzione che hai chiamato è completamente ignara dell'exploit.

Ho fatto qualche ricerca su questo, e questo tipo di exploit viene usato praticamente ovunque ovunque ora, in cose come l' esecuzione di homebrew su Wii e il jailbreak illimitato per iOS 4.3.1

La mia domanda è: perché questo problema è così difficile da risolvere? È ovvio che questo è uno dei principali exploit utilizzati per hackerare centinaia di cose, ma sembra che sarebbe abbastanza facile da risolvere semplicemente troncando qualsiasi input oltre la lunghezza consentita e semplicemente disinfettando tutti gli input che prendi.

EDIT: Un'altra prospettiva che vorrei prendere in considerazione le risposte: perché i creatori di C non risolvono questi problemi reimplementando le librerie?

Hanno corretto le librerie.

Qualsiasi libreria standard moderni C contiene varianti più sicuri strcpy, strcat, sprintf, e così via.

Sui sistemi C99 - che è la maggior parte degli Unix - li troverai con nomi come strncate snprintf, la "n" indica che serve un argomento delle dimensioni di un buffer o un numero massimo di elementi da copiare.

Queste funzioni possono essere utilizzate per gestire molte operazioni in modo più sicuro, ma a posteriori la loro usabilità non è eccezionale. Ad esempio alcune snprintfimplementazioni non garantiscono che il buffer sia terminato con null. strncatrichiede un numero di elementi da copiare, ma molte persone passano erroneamente la dimensione del buffer dest.

Su Windows, si trova spesso il strcat_s, sprintf_s, il suffisso "_s" che indica "sicuro". Anche questi si sono fatti strada nella libreria standard C in C11 e forniscono un maggiore controllo su ciò che accade in caso di overflow (troncamento vs. asserzione per esempio).

Molti fornitori offrono ancora più alternative non standard come asprintfnella libc GNU, che assegnerà automaticamente un buffer della dimensione appropriata.

L'idea che si possa "solo correggere C" è un malinteso. Correggere C non è il problema - ed è già stato fatto. Il problema sta risolvendo decenni di codice C scritto da programmatori ignoranti, stanchi o affrettati, o codice che è stato portato da contesti in cui la sicurezza non contava in contesti in cui la sicurezza lo fa. Nessuna modifica alla libreria standard può risolvere questo codice, sebbene la migrazione a compilatori e librerie standard più recenti possa spesso aiutare a identificare automaticamente i problemi.

Non è proprio inesatto affermare che C sia in realtà "soggetto a errori" in base alla progettazione . A parte alcuni gravi errori come gets, il linguaggio C non può davvero essere in nessun altro modo senza perdere la caratteristica principale che attira le persone in C in primo luogo.

C è stato progettato come linguaggio di sistema per agire come una sorta di "assemblaggio portatile". Una caratteristica importante del linguaggio C è che, a differenza dei linguaggi di livello superiore, il codice C spesso è molto simile al codice macchina effettivo. In altre parole, di ++isolito è solo incun'istruzione e spesso puoi avere un'idea generale di cosa farà il processore in fase di esecuzione guardando il codice C.

Ma l'aggiunta del controllo implicito dei limiti aggiunge un sacco di sovraccarico extra - sovraccarico che il programmatore non ha richiesto e potrebbe non desiderare. Questo sovraccarico va ben oltre l'archiviazione aggiuntiva richiesta per memorizzare la lunghezza di ciascun array o le istruzioni aggiuntive per controllare i limiti dell'array su ogni accesso dell'array. Che dire dell'aritmetica del puntatore? O se hai una funzione che accetta un puntatore? L'ambiente di runtime non ha modo di sapere se quel puntatore rientra nei limiti di un blocco di memoria legittimamente allocato. Per tenerne traccia, avresti bisogno di una seria architettura di runtime in grado di verificare ogni puntatore rispetto a una tabella di blocchi di memoria attualmente allocati, a quel punto stiamo già entrando nel territorio di runtime gestito in stile Java / C #.

Credo che il vero problema non è che questi tipi di insetti sono difficili da risolvere, ma che sono così facili da fare: se si utilizza strcpy, sprintfe amici nel (apparentemente) modo più semplice che il lavoro può, allora probabilmente avete ha aperto la porta per un overflow del buffer. E nessuno lo noterà finché qualcuno non lo sfrutta (a meno che tu non abbia ottime recensioni di codice). Ora aggiungi il fatto che ci sono molti programmatori mediocri e che sono sotto la pressione del tempo per la maggior parte del tempo - e hai una ricetta per il codice che è così pieno di buffer overflow che sarà difficile risolverli tutti semplicemente perché c'è così tanti di loro e si nascondono così bene.

È difficile correggere gli overflow del buffer perché C non fornisce praticamente strumenti utili per risolvere il problema. È un difetto di linguaggio fondamentale che i buffer nativi non forniscono protezione ed è praticamente, se non completamente, impossibile sostituirli con un prodotto superiore, come ha fatto C ++ con std::vectore std::array, ed è difficile persino in modalità debug trovare buffer overflow.

Il problema non è con la C la lingua .

IMO, l'unico grande ostacolo da superare è che C è semplicemente insegnato male . Decenni di cattive pratiche e informazioni errate sono stati istituzionalizzati nei manuali di riferimento e negli appunti delle lezioni, avvelenando le menti di ogni nuova generazione di programmatori sin dall'inizio. Agli studenti viene fornita una breve descrizione delle funzioni di I / O "facili" come gets¹ o, scanfquindi, lasciate ai propri dispositivi. Non viene detto dove o come tali strumenti possono fallire o come prevenirli. Non gli viene detto di usare fgetsestrtol/strtodperché quelli sono considerati strumenti "avanzati". Quindi vengono scatenati nel mondo professionale per provocare il loro caos. Non che molti dei programmatori più esperti conoscano meglio, perché hanno ricevuto la stessa educazione cerebrale. È esasperante. Vedo così tante domande qui e su Stack Overflow e su altri siti in cui è chiaro che la persona che pone la domanda viene insegnata da qualcuno che semplicemente non sa di cosa sta parlando , e ovviamente non puoi semplicemente dire "il tuo professore ha torto", perché è un professore e tu sei solo un ragazzo su Internet.

E poi hai la folla che disdegna qualsiasi risposta a cominciare, "beh, secondo lo standard linguistico ..." perché stanno lavorando nel mondo reale e secondo loro lo standard non si applica al mondo reale . Posso avere a che fare con qualcuno che ha una cattiva educazione, ma chiunque insista a essere ignorante è solo una rovina per l'industria.

Non ci sarebbero problemi di buffer overflow se la lingua fosse insegnata correttamente con un'enfasi sulla scrittura di codice sicuro. Non è "difficile", non è "avanzato", sta solo facendo attenzione.

Sì, questo è stato un rant.

Il problema è tanto quello della miopia gestionale che quello dell'incompetenza del programmatore. Ricordate, un'applicazione 90.000-line ha bisogno solo di un'operazione insicuro per essere completamente insicura. È quasi al di là delle possibilità che qualsiasi applicazione scritta sulla gestione delle stringhe fondamentalmente insicure sia perfetta al 100%, il che significa che sarà insicura.

Il problema è che i costi di insicurezza non sono addebitati al destinatario giusto (la società che vende l'app non dovrà quasi mai rimborsare il prezzo di acquisto) o non sono chiaramente visibili al momento in cui vengono prese le decisioni ("Dobbiamo spedire a marzo non importa cosa! "). Sono abbastanza certo che se considerassi i costi e i costi a lungo termine per i tuoi utenti piuttosto che per i profitti della tua azienda, scrivere in C o in lingue correlate sarebbe molto più costoso, probabilmente così costoso che è chiaramente la scelta sbagliata in molti campi in cui oggigiorno la saggezza convenzionale dice che è una necessità. Ma ciò non cambierà a meno che non venga introdotta una responsabilità software molto più rigorosa, che nessuno nel settore desidera.

Uno dei grandi poteri dell'uso di C è che ti consente di manipolare la memoria come preferisci.

Uno dei maggiori punti deboli dell'uso di C è che ti consente di manipolare la memoria come preferisci.

Esistono versioni sicure di tutte le funzioni non sicure. Tuttavia, i programmatori e il compilatore non applicano rigorosamente il loro uso.

perché i creatori di C non risolvono questi problemi reimplementando le librerie?

Probabilmente perché C ++ lo ha già fatto ed è retrocompatibile con il codice C. Quindi, se vuoi un tipo di stringa sicuro nel tuo codice C, devi solo usare std :: string e scrivere il tuo codice C usando un compilatore C ++.

Il sottosistema di memoria sottostante può aiutare a prevenire gli overflow del buffer introducendo blocchi di guardia e controllandone la validità - quindi a tutte le allocazioni sono aggiunti 4 byte di "fefefefe", quando questi blocchi vengono scritti, il sistema può lanciare un wobbler. Non è garantito per impedire una scrittura della memoria, ma mostrerà che qualcosa è andato storto e deve essere riparato.

Penso che il problema sia che le vecchie routine strcpy etc sono ancora presenti. Se fossero stati rimossi a favore di strncpy ecc., Sarebbe stato d'aiuto.

È semplice capire perché il problema di overflow non è stato risolto. C era difettoso in un paio di aree. All'epoca quei difetti erano visti come tollerabili o addirittura come una caratteristica. Ora, decenni dopo, quei difetti non sono risolvibili.

Alcune parti della comunità di programmatori non vogliono tappare quei buchi. Guarda tutte le guerre di fiamma che ricominciano da stringhe, array, puntatori, raccolta dei rifiuti ...