In realtà la maggior parte delle lingue sono "sicure" per quanto riguarda i buffer overflow. Ciò che serve perché un linguaggio sia "sicuro" sotto questo aspetto è la combinazione di: tipi rigorosi, controlli sistematici associati ad array e gestione automatica della memoria (un "garbage collector"). Vedi questa risposta per i dettagli.

Alcuni vecchi linguaggi non sono "sicuri" in questo senso, in particolare C (e C ++), e anche Forth, Fortran ... e, ovviamente assemblaggio. Tecnicamente , è possibile scrivere un'implementazione di C che sia "sicura" e comunque formalmente conforme allo standard C, ma a un prezzo elevato (ad esempio, devi rendere libero () nessuna operazione, quindi la memoria allocata viene allocata "per sempre"). Nessuno lo fa.

I linguaggi "protetti" (per quanto riguarda i buffer overflow) includono Java, C #, OCaml, Python, Perl, Go e persino PHP. Alcuni di questi linguaggi sono più che abbastanza efficienti per implementare SSL / TLS (anche su sistemi embedded - parlo per esperienza). Sebbene sia possibile scrivere codice C sicuro, ci vuole (molta) concentrazione e abilità, e l'esperienza mostra ripetutamente che è difficile e che anche i migliori sviluppatori non possono fingere che applicare sempre i livelli di concentrazione e competenza richiesti. Questa è un'esperienza umiliante. L'affermazione "non usare C, è pericoloso" è impopolare, non perché sarebbe sbagliato, ma, al contrario, perché è vero: costringe gli sviluppatori ad affrontare l'idea che potrebbero non essere i semidei di programmazione che credono di essere, nel profondo della privacy delle loro anime.

Nota, però, che questi linguaggi "sicuri" non prevengono il bug: un overflow del buffer è ancora un comportamento indesiderato. Ma contengono il danno: la memoria oltre il buffer non viene effettivamente letta o scritta; invece, il thread offensivo attiva un'eccezione e viene (solitamente) terminato. Nel caso di heartbleed, questo avrebbe evitato che il bug diventasse una vulnerabilità e avrebbe potuto aiutare a prevenire il panico su larga scala che abbiamo osservato negli ultimi giorni (nessuno sa davvero cosa rende un la vulnerabilità casuale diventa virale come un video di Youtube con un cavallo invisibile coreano; ma, "logicamente", se non fosse stata affatto una vulnerabilità, allora questo avrebbe dovuto evitare tutta questa tragicommedia).

Modifica: poiché è stato ampiamente discusso nei commenti, ho pensato al problema della gestione sicura della memoria per C, e c'è una sorta di soluzione che consente ancora free () per funzionare, ma c'è un trucco.

Si può immaginare un compilatore C che produca "fat pointer". Ad esempio, su una macchina a 32 bit, crea puntatori con valori a 96 bit. Ad ogni blocco allocato verrà concesso un identificatore univoco a 64 bit (ad esempio, un contatore) e viene mantenuta una struttura di memoria interna (tabella hash, albero bilanciato ...) che fa riferimento a tutti i blocchi in base all'ID. Per ogni blocco viene registrata anche la sua lunghezza nella struttura. Un valore del puntatore è quindi la concatenazione dell'ID del blocco e un offset all'interno di quel blocco. Quando viene seguito un puntatore, il blocco viene individuato per ID, l'offset viene confrontato con la lunghezza del blocco e solo allora viene eseguito l'accesso. Questa configurazione risolve double-free e use-after-free. Rileva anche la maggior parte dei sovraccarichi del buffer (ma non tutti: un buffer può essere parte di una struttura più grande, e il malloc () / free () management vede solo i blocchi esterni).

Il "trucco" è il "contatore unico a 64 bit". Questo è vero solo finché non si esauriscono i numeri interi a 64 bit; oltre a ciò, è necessario riutilizzare i vecchi valori. 64 bit dovrebbero evitare questo problema in pratica (ci vorrebbero anni per "concludere"), ma un contatore più piccolo (ad esempio 32 bit) potrebbe rivelarsi un problema.

Inoltre, ovviamente, il il sovraccarico per gli accessi alla memoria può essere non trascurabile (un bel po 'di letture fisiche per ogni accesso, sebbene alcuni casi possano essere ottimizzati), e il raddoppio della dimensione del puntatore implica anche un maggiore utilizzo della memoria per strutture ricche di puntatori. Non sono a conoscenza di alcun compilatore C esistente che applichi tale strategia; al momento è puramente teorico.

Il linguaggio Ada è progettato per prevenire il più possibile errori di programmazione comuni ed è utilizzato in sistemi critici in cui un bug di sistema potrebbe avere conseguenze catastrofiche.

Alcuni esempi in cui Ada va oltre la tipica sicurezza incorporata fornita da altri linguaggi moderni:

• Il tipo di intervallo intero consente di specificare un intervallo consentito per un numero intero. Qualsiasi valore al di fuori di questo intervallo genererà un'eccezione (nelle lingue che non supportano un tipo di intervallo, dovrebbe essere eseguito un controllo manuale).

• : = per l'assegnazione = per i controlli di uguaglianza. Ciò evita la trappola comune nelle lingue che usano = per l'assegnazione e == per l'uguaglianza di assegnazione accidentale quando si intendeva un controllo di uguaglianza (in Ada, un'assegnazione accidentale non si compilerebbe ).

• in e out parametri che specificano se un parametro del metodo può essere letto o scritto

• evita problemi con i livelli di indentazione del gruppo di istruzioni (ad esempio il recente bug SSL di Apple) a causa dell'uso della parola chiave end

• i contratti (da Ada 2012 e in precedenza nel sottoinsieme SPARK) consentono ai metodi di specificare le precondizioni e le postcondizioni che devono essere soddisfatte

Lì sono altri esempi di come Ada è stato progettato per la sicurezza fornito nel Libretto sicuro e protetto (PDF).

Naturalmente, molti di questi problemi possono essere mitigati attraverso uno stile di codifica appropriato, revisione del codice, test unitari, ecc. ma averli eseguiti a livello di lingua significa che li ottieni gratuitamente.

vale anche la pena aggiungere che, nonostante il fatto che un linguaggio progettato per la sicurezza come Ada rimuova molte classi di bug, non c'è ancora nulla che ti impedisca di introdurre bug di logica aziendale di cui il linguaggio non sa nulla.

La maggior parte dei linguaggi di programmazione di livello superiore al C sono molto più sicuri quando si tratta di errori di programmazione come quelli di Heartbleed. Esempi che si compilano principalmente in codice macchina includono D, Rust e Ada. Non è interessante parlare solo della sicurezza della memoria, secondo me.

Ecco un elenco di funzionalità aggiuntive del linguaggio di programmazione che (penso) rendono molto più difficile scrivere codice non sicuro. Le prime cinque funzionalità espandono le capacità del compilatore nel ragionamento sul tuo codice, quindi tu , un essere umano incline a commettere errori, non devi *. Inoltre, queste caratteristiche dovrebbero anche rendere più facile per un altro essere umano, un auditor, ragionare sul tuo codice. Il codice sorgente di OpenSSL è spesso descritto come un pasticcio e un linguaggio più rigoroso di C avrebbe potuto aiutare a rendere più facile ragionare. Le ultime due funzionalità riguardano problemi di contesto che influenzano anche la sicurezza.

• Un sistema di tipi rigorosi: rende più facile ragionare sulla correttezza del programma. Elimina alcuni attacchi di input.
• Immutabile per impostazione predefinita: avere valori immutabili come contenitore di dati primario significa che è molto più facile ragionare sullo stato del tuo programma.
• Disabilitato o limitato non sicuro: Non permettere cose spaventose come l'aritmetica del puntatore (es. Go), o almeno permetterlo solo se racchiuso in grossi avvisi (Rust). Tieni presente che un linguaggio privo completamente di aritmetica dei puntatori è escluso per l'uso in un numero enorme di applicazioni che richiedono un accesso di basso livello.
• Tempo di compilazione controllo della contaminazione : espande il sistema di tipi per consentire l'identificazione di valori contaminati : valori che dipendono in qualche modo in base all'input. Il compilatore potrebbe quindi (condizionatamente) vietare operazioni con un valore contaminato che fanno trapelare informazioni a osservatori esterni, come la ramificazione su tale valore. Ciò potrebbe impedire o almeno migitare determinate classi di attacchi temporali. Per quanto ne so, questi sono disponibili solo negli strumenti di analisi del codice statico e non nei compilatori stessi?
• Tipi dipendenti: i tipi dipendenti sono un mezzo per dire al compilatore che "quièun Int i cui valori sono compresi tra 2 e 87" o "quièuna Stringa di lunghezza massima 12 contenente solo caratteri alfanumerici ". Il mancato rispetto di questi requisiti provoca un errore di compilazione e non un errore di runtime con risultati probabilmente non sicuri. Questa funzione è disponibile in Idris e in alcuni linguaggi di dimostrazione di teoremi.
• Assenza di garbage collection: la garbage collection è un grosso problema per la sicurezza del linguaggio - crea pause di garbage collection nel tuo programma. Questi interrompono le informazioni sulle perdite sullo stato del programma e consentono che si verifichino attacchi temporali. Quando il garbage collector viene invocato è impossibile (o nella migliore delle ipotesi incredibilmente difficile) da prevedere come sviluppatore, tuttavia, e soggetto a enormi cambiamenti anche per la più piccola quantità di modifiche al codice.
• Prestazioni, portabilità Interopabilità di &: Potrebbe andare bene se hai bisogno di un programma sicuro e lento che gira solo sulla piattaforma PowerPC, ma non aspettarti che qualcun altro lo utilizzi per una libreria TLS multipiattaforma. OpenSSL è popolare proprio perché è veloce e funziona ovunque, da oscuri router basati su MIPS a server SPARC in parallelo massicciamente e tutto il resto. Inoltre qualsiasi programma o runtime nel mondo può interfacciarsi con OpenSSL come libreria perché utilizza convenzioni di chiamata C.

Dalla mia conoscenza limitata delle lingue, nessun linguaggio lo fa tutti questi. Rust è un esempio di un linguaggio che copre molti: è rigoroso, immutabile per impostazione predefinita, ha limitazioni di sicurezza, non richiede la raccolta dei rifiuti ed è abbastanza performante e portatile. Il controllo della contaminazione in fase di compilazione e i tipi dipendenti attualmente sembrano essere funzionalità esotiche che richiedono strumenti aggiuntivi di analisi statica del codice o nuovi linguaggi, purtroppo.

* Vedi anche: verifica formale

Nello spirito generale di ciò che stai chiedendo, penso che il linguaggio E (la "piattaforma distribuita sicura per oggetti puri e linguaggio di scripting p2p") sia piuttosto interessante, in quanto sta tentando per offrire in modo sicuro funzionalità / modelli di calcolo non generalmente disponibili.

All current (meaning still updated) programming languages are designed to have as few inherent security flaws as possible, but at the end of the day it's (almost always) the programmer who is responsible for security flaws, not the language he's using.

EDIT: As @DCKing pointed out, not all languages are equal, and I'm not saying it's a good idea to pick one at random and try and make it work. I am saying that a (very) talented C programmer can make a program just as secure as a semantically identical program written in a higher level language. My point is that we should recognize that some languages make it easier to make mistakes, but also know that in the end it's the programmer's mistake, not the language's (with few exceptions)

Non esiste una lingua sicura. Se una lingua fornisce una sicurezza sufficiente per il tuo problema, dipende molto dal problema che stai cercando di risolvere. Ad esempio, se stai scrivendo un'applicazione web, la sicurezza della maggior parte dei linguaggi utilizzati in questo contesto (ad esempio Java, PHP, JavaScript ... aggiungi il tuo preferito) è sufficiente per evitare cose come il buffer overflow, ma anche i linguaggi più fortemente tipizzati non lo fanno offrire supporto intrinseco per cose specifiche del web, ad es come rendere impossibile o almeno difficile introdurre bug di Cross-Site-Scripting o simili. E nessuna lingua ti proteggerà da un modello di fiducia errato, come la fiducia nei server DNS (riassociazione DNS ecc.), L'attuale modello PKI o includendo script di terze parti (ad es. Fuori dal tuo controllo) nella tua applicazione web (in genere annunci o Google Analytics) .

Quindi la scelta di una lingua corretta potrebbe aiutarti un po ', ma non esiste una spada magica di sicurezza.

Ricorda che per la maggior parte dei linguaggi di programmazione, devi preoccuparti della sicurezza di due linguaggi. C'è la lingua che stai effettivamente utilizzando, e poi c'è la lingua in cui sono scritti il ​​compilatore o l'interprete, che spesso è diversa. (Tecnicamente, ce n'è un terzo, che è il microcodice della CPU stessa.) Un problema di sicurezza in uno di questi linguaggi può rendere insicuro il tuo programma.

In primo luogo, in realtà non scrivi programmi in linguaggi di programmazione. Scrivi istruzioni per il compilatore che descrive che tipo di programma vuoi, e il compilatore produce un programma, nel suo modo peculiare, che si spera (se il tuo compilatore è ben progettato) fare la stessa cosa descritta dal codice sorgente. Tutti i programmi, quando sono in esecuzione, sono in "linguaggio macchina" - sono una serie di numeri che vengono interpretati in un certo modo quando vengono caricati nella RAM e inseriti nella CPU. Il linguaggio macchina non è progettato pensando alla robustezza dell'hacking, quindi nessun linguaggio compilato può essere veramente "resistente" all'hacking, perché il programma effettivo sarà comunque in linguaggio macchina. Qualsiasi linguaggio interpretato o VM continuerà a funzionare in un framework nativo che è compilato alla fine in linguaggio macchina, quindi il problema persiste.

In secondo luogo, la maggior parte dei linguaggi reali sono completi di Turing. Ciò significa che qualsiasi compito che può essere svolto da uno di loro può essere portato a termine da tutti. Pertanto, non è possibile rendere impossibile "l'hacking" (se l'hacking significa scrivere programmi dannosi); romperebbe la completezza di Turing.

A questo punto vale la pena chiarire cosa intendi per hacking. Dato che hai menzionato Heartbleed, immagino che tu non lo intenda nel senso di Stallman ("armeggiare scherzoso").

Se intendi persone che scrivono programmi che accedono direttamente alla memoria e rubano dati o modificano altri programmi (come virus o keylogger), questo non è un problema che una lingua può davvero affrontare. Un compilatore può aiutare, avendo una funzione aggiuntiva per produrre codice macchina offuscato durante la compilazione, ma alla fine è ancora possibile per un abile hacker della memoria trovare la sua strada. La soluzione a questo problema è la progettazione del sistema operativo: un sistema operativo dovrebbe eseguire il sandbox dei programmi e non consentire a un programma di alterare la memoria che appartiene a un altro programma. Questo fa parte di ciò che fa l'UAC in Windows (sebbene Sandboxie sia un esempio migliore).

C'è un avvertimento qui: alcuni linguaggi, come C # o Java hanno funzionalità (più correttamente, il compilatore e la VM in cui vengono eseguiti i programmi hanno funzionalità) che controllano se qualche programma sta cercando di masticare nella memoria di un altro programma, e quando ciò accade genera errori come IllegalAccessException (ad esempio, keylogger.exe non dovrebbe essere in grado di leggere il valore Credit_card_number da internet banking application.exe ). Ovviamente, questo richiede di tenere traccia di quale memoria appartiene a quale programma, che ha alcune prestazioni e costi di impegno non banali. Alcuni linguaggi "più semplici" come il C non ce l'hanno - questo è il motivo per cui molti hack come i virus sono scritti in C. Oggigiorno devi essere intelligente nell'eludere l'UAC, ma ai tempi di Windows 98 le persone potevano fare di tutto di cose folli sul tuo computer / sistema operativo leggendo e scrivendo in memoria che non avrebbero dovuto. Nota che anche in C # hai ancora la possibilità di usare normali puntatori simili a C (che i linguaggi chiamano unsafe e richiedono di contrassegnare come tali nel codice) se lo desideri, sebbene CLR probabilmente lo farà contenere il tuo hack al suo interno, a meno che non trovi un buco di sicurezza nel CLR che ti permetta di entrare nel resto della memoria.

Il secondo tipo di hacking è sfruttare un bug in un programma esistente. Questa è la categoria a cui appartiene il cuore sanguinante. Con questo, la domanda è se il programmatore commette un errore o meno. Ovviamente se la tua lingua è qualcosa come Brainfuck o Perl che è molto difficile da leggere, è probabile che commetterai degli errori. Seèun linguaggio con molti "gotcha" come C ++ (vedi "classico" if (i = 1) vs. if (i == 1) o il C contest di offuscamento) quindi potrebbe essere difficile cogliere gli errori. In questo senso, progettare per la sicurezza è in realtà solo un banale caso speciale di progettazione per ridurre al minimo gli errori del programmatore.

Nota che il bug Heartbleed, sia che si tratti di un sabotaggio intenzionale o di un errore onesto, era un problema con l ' algoritmo utilizzato (l'autore "si è" dimenticato "di controllare la dimensione), quindi nessun compilatore a meno di un'IA come intelligente come un essere umano molto intelligente potrebbe sperare di rilevarlo; sebbene la violazione di accesso risultante, plausibilmente, avrebbe potuto essere colta con una gestione intelligente della memoria.

In conclusione

Ci sono due tipi di preoccupazioni riguardo all'hacking:

1. Un programma è stato programmato in modo errato e ti consente di fare cose che non dovresti. Per esempio. Il server Gmail consente a tutti di vedere le tue e-mail, invece di richiedere loro di inserire prima il nome utente e la password corretti, perché qualcuno ha commesso un errore durante lo sviluppo del software del server. Include bug, vulnerabilità, ecc.

2. Un programma viene manipolato dal programma dannoso dell'hacker. Include virus, keylogger e altri malware.

(1) può essere risolto rendendo un linguaggio più rigoroso ed esplicito, in modo che il rilevamento degli errori sia più facile, ma alla fine solo molto semplice gli errori possono essere rilevati da strumenti automatizzati e, per quanto riguarda i "tripwires" come il controllo della portata di Ada, si può sostenere che riconoscere la possibilità di un errore è necessario per pensare di aggiungere il controllo in primo luogo, e riconoscere la possibilità è già la parte più difficile.

(2) non può essere risolto cambiando la lingua. Se crei un linguaggio in cui è molto difficile scrivere applicazioni malvagie, gli hacker useranno semplicemente un altro linguaggio e non avranno difficoltà aggiuntive a manipolare i programmi scritti nella tua lingua perché alla fine vengono comunque eseguiti come codice macchina. Può essere risolto creando un sistema operativo che controlli molto attentamente i programmi in esecuzione al suo interno, ma poi diventa una questione di (1) problemi di tipo nel codice sorgente del sistema operativo .

Esistono molte lingue sicure. Direi che un linguaggio con gestione della memoria e thread safety è sicuro quanto un linguaggio può ottenere.

Tuttavia, la maggior parte di questi sono inefficienti. La raccolta dei rifiuti è costosa e le lingue interpretate lo sono di più. Ed è per questo che fino ad oggi le applicazioni di grandi dimensioni sono scritte in un C / C ++ non sicuro per la memoria.

Recentemente ho giocato con Rust e a me sembra essere un linguaggio "sicuro" nel senso che è stato in parte progettato per questo.

È un linguaggio compilato come C ++ e offre anche puntatori e concorrenza. (Garbage Collector non necessario)

Tuttavia, non trascura la sicurezza della memoria dei puntatori e la concorrenza con esso. Rust è un linguaggio che non si fida del programmatore e in fase di compilazione controlla l'utilizzo sospetto dei puntatori. Esistono più tipi di puntatori / riferimenti (presi in prestito, posseduti, ecc.) E alcuni di essi hanno regole rigide su di essi. Ad esempio, non si può:

• prendere un riferimento a un puntatore di proprietà e quindi mutare il puntatore di proprietà
• passare un riferimento al di fuori della durata di un oggetto (i riferimenti non sono t solo numeri che possono essere battuti come in C ++)
• spostarsi su un puntatore di proprietà e accedere alla variabile originale

Esistono regole simili che garantiscono la sicurezza del thread. Se si desidera, possono bypassare molti di questi controlli utilizzando caselle contrassegnate come non sicure ("fidati di me, so cosa sto facendo"), o rallentare i puntatori raccolti dai rifiuti. Esistono anche modi più rustici (ed efficienti) per farlo utilizzando una combinazione di cloni e riferimenti, che variano a seconda dell'utilizzo.

I linguaggi Managed Type Safe fanno molto per prevenire questo genere di cose fornendo la convalida dei tipi automaticamente e spostando ulteriormente l'esecuzione del codice dalla CPU stessa, tuttavia ciò non esclude la possibilità di bug nell'implementazione del sistema utilizza la lingua per eseguire il mapping alla CPU (ad esempio, CLR in .Net o JVM in Java). Inoltre non esclude la possibilità di bug in un'applicazione che potrebbe renderla vulnerabile alla manipolazione o alla perdita di dati per se stessa.

Migliorano notevolmente la sicurezza del sistema, ma anche sono più voluminosi, più lenti e più limitati nelle funzioni a causa del sovraccarico del motore di esecuzione che devono eseguire per fornire quella funzionalità.

Ci sono certamente lingue progettate per essere sicure, ma nessuna perfetta. Ada, ad esempio, ti consente di specificare un intervallo consentito per le variabili intere e genera un'eccezione se escono da tale intervallo. Suona bene, ti ho risparmiato il controllo manuale. Il problema è che se non devi controllare manualmente è facile impostare questo meccanismo e poi dimenticare di considerare le conseguenze, cioè eccezioni di numero intero fuori intervallo. Hai appena creato un vettore per gli attacchi Denial of Service.

La sicurezza è un processo. Il linguaggio può aiutare, ma nella migliore delle ipotesi può solo ridurre la possibilità di errori e nel processo di solito ne crea di nuovi e spesso anche più sottili. Probabilmente il C, per natura più facile da comprendere appieno e completamente deterministico (nessuna raccolta di dati inutili in background, ad esempio), è ideale per scrivere codice sicuro. E abbastanza sicuro, quando guardi un sacco di codice critico per la sicurezza è scritto in C. Per essere onesti con Ada, si tratta più di affidabilità che di sicurezza.