Argomenti per il corso SecureCoding in C

Raccomando di consultare il sommario di " L'arte della valutazione della sicurezza del software " alias TAOSSA . Ha tutto a posto, niente da reinventare.

Inoltre, vedo che nella tua lista manca una cosa importante - trattare con i puntatori. Suppongo che per quell'articolo ci dovrebbe essere un argomento separato. Questa è una vera PITA e l'attenzione dovrebbe essere rivolta a questo problema sin dall'inizio.

Quindi, puoi dare un'occhiata qui: link a mostra "le peggiori pratiche".

Infine, oggi è molto importante attirare l'attenzione sul software x64. Una buona lettura può essere trovata qui: link

So che questo è al di fuori degli aspetti specifici di C, ma ritengo che sia appropriato per insegnare a qualsiasi sviluppatore:

• Convalida dell'input e codifica dell'output

Fatti coinvolgere da quell'idea. Indipendentemente dal fatto che finisci per fare un po 'di giro con SQL Injection, vale comunque la pena di insegnare la mentalità "non fidarti di niente al di fuori del tuo controllo"!

Aggiornamento - Avere un rapido controllo di integrità osservando le mie note di revisione del codice mi dà anche:

• Mancato rilascio delle risorse che portano a DoS o stati di blocco

So che questa risposta sarà impopolare, ma direi alla gente di interrompere la programmazione in C o qualsiasi codice non gestito. Le ottimizzazioni JIT nei framework di codice gestito sono ottimizzate al meglio (che è qualcosa di cui non dovresti preoccuparti in primo luogo come sviluppatore) nel 2011.

Nel caso di brownfield, devons legacy, dovrebbero utilizzare un compilatore diverso, ad esempio uno basato sulla sicurezza costruito su una lingua vicina. Sarà più facile fare questo che scrivere specifiche formali in Z per essere tradotte in Hoare Logics - sebbene Klocwork Insight (come discusso in Hacking Exposed Linux, 3rd Edition) possa essere di aiuto con questo progetto potenzialmente di 70 anni che hai appena creato per te stesso.

Sarebbe bello sapere che tipo di software è - e quale infrastruttura e gestione del rischio è comunemente applicata attorno ad esso. Il progetto SATE sarebbe un buon posto per rendersi conto che gli strumenti di analisi statica incentrati sulla sicurezza e la confusione non saranno di aiuto da soli. Se si desidera la garanzia del software, è necessario cambiare la lingua o adottare metodi formali. Quelle sono le opzioni.

A rischio di non rispondere alla domanda, vorrei certamente indicarti i principi di sviluppo protetto di David Rook (aka @securityninja) su securityninja.co.uk .

Anche se non ti aiuterà con le specificità di una particolare lingua, personalmente trovo il suo approccio preciso. Usa l'analogia dell'apprendimento per guidare un'auto. Piuttosto che insegnare alle persone come far crollare una macchina in modi diversi (pensate agli exploit), insegniamo loro come eseguire le manovre di base, ecc. (Pensate alla codifica input / output come @RoryAlsop ha detto) che si spera significhi che evitino i crash.

Come ho detto, non è esattamente una risposta alla tua domanda specifica, ma spero che sia una risorsa preziosa per te e per coloro che si trovano in una posizione simile.

Ciò che hai elencato è sicuramente molto importante e dovrebbe essere coperto.

Se io insegnassi la classe, per prima cosa introdurrei gli studenti a Smashing the Stack for Fun and Profit e come l'overflow del buffer basato sullo stack può essere utilizzato per corrompere il frame dello stack per una funzione in cui ti trovi e controllare l'indirizzo di ritorno. Otterrei una vecchia macchina XP SP1 e OllyDBG e seguirò il processo di sfruttamento dell'intera classe. (Oppure se vai con un esempio di aleph, puoi usare una moderna disto Linux con i sistemi di protezione della memoria disabilitati)

Quindi dovresti coprire i moderni sistemi difensivi come: ASLR, Canarie e Zone NX. Se si guardano gli exploit moderni che sono in grado di funzionare in questo ambiente, non si vedranno overflow del buffer basati sullo stack. Vedrai puntatori penzolanti . Un ottimo esempio è Pwn2Own for 2010 contro IE8 + Windows7 .

Penso anche che sia necessario capire come questi problemi si trovano nel mondo reale. Ad esempio strutture a sfocato come la pesca (ottimo compito a casa!). Include anche strumenti di analisi del codice come RATS (open source) e Coverity ($$$). Valgrind è anche interessante, specialmente se vai a puntatori penzolanti.

Anche il blog di Metasploit è davvero buono. Mi piacciono i post sull'analisi degli exploit.

Non menzioni le buone abitudini di programmazione generali. Progettare per contratto, essere espliciti sulla gestione della memoria delle tue funzioni, cercare interfacce pulite - la disciplina qui coinvolta potrebbe andare oltre, ma rende molto più facile individuare potenziali problemi.

Su sistemi UNIX come un dereference NULL può essere effettivamente sfruttabile in un contesto del kernel, quindi è molto importante sottolineare il controllo religioso delle funzioni di allocazione della memoria.

In userland può solo causare arresti anomali (a meno che qualcuno non intrappoli SIGSEGV e il gestore di segnale sia vulnerabile, ma non sono a conoscenza di casi in cui SIGSEGV intrappola sarebbe una cosa intelligente da fare).

La conoscenza della sicurezza più utile non è la lingua o la piattaforma specifica, quindi è meglio cercare di insegnare i principi generali della 'codifica sicura' e mostrare esempi in 'C', piuttosto che insegnare 'codifica sicura in' C ' '.

Ad esempio, la comprensione del principio di "negazione di default" è una visione fondamentale che funziona in una miriade di contesti, lingue e piattaforme e copre intere classi di vulnerabilità. Nega per impostazione predefinita porta alla convalida dell'input, che a sua volta è una difesa contro l'overflow del buffer, gli attacchi con stringhe di formato e molti altri.