I linguaggi di programmazione potrebbero essere vulnerabili? [chiuso]

Ken Thompson ha scritto di questo esatto problema nel 1984 nel suo famoso articolo " Riflessioni su Trust Trust ".

Nel documento, discute un compilatore scritto in C che compila il codice C, 'bootstrapping' stesso. Quindi aggiunge una riga che compila il codice C con un bug intenzionale (usando l'esempio di una password hard-coded) e ottiene quello approvato come compilatore C "ufficiale", creando un cavallo di Troia. Infine, aggiunge un secondo bug che nasconde il primo bug. Compila di nuovo il compilatore, che rimuove il codice visibile che ha creato il bug, ma lascia il cavallo di Troia nel binario del compilatore. Sottolinea inoltre che tali fandonie possono essere eseguite a qualsiasi livello: assemblatore, compilatore, caricatore o microcodice hardware.

La conclusione logica era che non puoi fidarti del codice su un computer che non ti sei completamente creato e nessun livello di controllo può identificare questi problemi.

Dato che questo è stato presentato prima che venisse approvato il CFAA, il suo ultimo punto era che, dal momento che non siamo mai in grado di dimostrare un sistema affidabile, abbiamo invece bisogno di creare un deterrente e richiedere una punizione più dura per l'hacking nei sistemi di altre persone.

Questo documento e le idee sono classiche e sono rimaste pertinenti per la sicurezza nel corso della storia dell'informatica. È molto breve Dagli una lettura e vedi se soddisfa la tua curiosità o alimenta la tua paranoia.

"Vulnerabilità" ha molti significati. Nel contesto dei linguaggi di programmazione è possibile prendere in considerazione problemi di progettazione che favoriscono la scrittura di codice non sicuro come vulnerabilità del linguaggio di programmazione specifico. Ad esempio, la gestione manuale della memoria, le specifiche della gestione delle stringhe e i controlli dei limiti impliciti mancanti sono problemi importanti nella scrittura del codice C. Altri linguaggi di programmazione sono stati appositamente progettati per evitare tali problemi (spesso a costo di alcune prestazioni).

Simile potrebbe essere considerato una vulnerabilità del PHP come linguaggio incentrato sullo sviluppo web che ha reso molto facile creare dinamicamente una pagina web ma ha reso molto più difficile farlo in un modo sicuro, vale a dire correttamente l'escape e la codifica del output in base al contesto corrente. Ecco perché molte applicazioni PHP sono vulnerabili a XSS e simili.

Anche le librerie di base con valori predefiniti non sicuri o un'API che privilegia un codice non sicuro possono essere considerate una vulnerabilità del linguaggio di programmazione. Ad esempio, per molto tempo lo stack SSL in lingue importanti come Python o PHP non ha controllato correttamente i certificati nelle connessioni SSL per impostazione predefinita e quindi l'applicazione era vulnerabile agli attacchi man in the middle a meno che non lavorassero specificamente attorno alle impostazioni di sicurezza non sicure.

E a volte ci sono comportamenti debolmente o esplicitamente indefiniti per specifiche affermazioni in linguaggi di programmazione che non portano a errori di compilazione ma a codice diverso e talvolta insicuro a seconda del compilatore o dei flag, spesso a seconda del livello di ottimizzazione. Questi potrebbero essere considerati una vulnerabilità della lingua anche in quanto tale tipo di dichiarazioni non sono esplicitamente vietate e devono essere rifiutate da qualsiasi implementazione.

E poi ci possono essere ovviamente compilatori con backdoor che creano sempre in binari con backdoor. E ci sono errori di sicurezza nelle librerie. Ma queste non sono vulnerabilità del linguaggio stesso (ad esempio, come specificato o documentato) ma solo dell'implementazione specifica.

I computer non funzionano in una "lingua" di 0 e di 1. Una lingua è semplicemente un modo di interpretare gli 0 e gli 1 per significare qualcosa. Se aiuta, pensa a 0 e a 1 come lettere dell'alfabeto; il linguaggio è la formulazione di quelle lettere in combinazioni che hanno un significato intrinseco.

È per questo che i virus che hanno avuto un impatto, ad esempio, su Windows 95, non hanno avuto alcun impatto su un Mac (o viceversa). Si potrebbe avere lo stesso schema di 0 e 1, ma ogni computer ha interpretato ciò che intendevano in modo diverso. Da un lato, un comportamento devastante; dall'altro, codice non eseguibile.

Quindi no, non esiste una vulnerabilità utilizzando il sistema binario. Una vulnerabilità / virus / qualunque cosa non sia un problema con gli 0 e gli 1 - è come il computer interpreta quegli 0 e gli 1.