Analisi del codice: binario vs origine

Dipende dalla situazione - tipo di applicazione, modello di implementazione, in particolare il modello di minaccia, ecc.

Ad esempio, alcuni compilatori possono sostanzialmente modificare alcuni codici delicati, introducendo sottili difetti, come l'esclusione di alcuni controlli, che appaiono nel codice (soddisfacendo la revisione del codice) ma non nel binario (in mancanza del test di realtà). < br> Inoltre ci sono alcuni rootkit a livello di codice - hai citato C ++, ma ci sono anche rootkits di codice gestito per es. .NET e Java: evaderebbero completamente la revisione del codice, ma verranno visualizzati nei file binari distribuiti.
Inoltre, lo stesso compilatore potrebbe avere determinati rootkit, che consentirebbero l'inserimento di backdoor nella tua app. (Vedi un po 'di storia del rootkit originale - il compilatore ha inserito una password backdoor nello script di accesso e ha anche inserito questa backdoor in il compilatore stesso quando si ricompila dal codice "pulito"). Di nuovo, manca dal codice sorgente ma presente nel file binario.

Detto questo, è ovviamente più difficile e dispendioso in termini di tempo fare il reverse engineering del binario, e sarebbe inutile negli scenari più se hai già il codice sorgente.
Voglio sottolineare questo punto: se hai il codice sorgente, non disturbare nemmeno con RE finché non hai ripulito tutte le altre vulnerabilità che hai trovato tramite revisione del codice, pentesting, fuzzing, modellazione di minacce, ecc. E anche in questo caso, solo preoccuparsi se si tratta di un'app altamente sensibile o estremamente visibile.
I casi limite sono abbastanza difficili da trovare, e abbastanza rari, che i tuoi sforzi possano essere meglio spesi altrove.

D'altro canto, si noti che ci sono alcuni prodotti di analisi statici che analizzano in modo specifico i binari (ad esempio, Veracode), quindi se si sta utilizzando uno di questi non ha molta importanza ...

@AviD punti solidi, totalmente d'accordo sui rootkit sul componente binari / compilatori.

Se sei un professionista sec esperto, mettendo da parte i punti validi di AviD, la maggior parte delle vulnerabilità sarà probabilmente nel tuo codice sorgente. Avere una solida conoscenza della programmazione in sicurezza e il modo in cui viene eseguita la retroingegnerizzazione dovrebbe darti il metodo migliore per correggere / prevenire la maggior parte dei buchi nel tuo codice sorgente. Inoltre, se c'è un exploit con un compilatore / binario, molte volte non c'è nulla che tu possa fare come uno sviluppatore per impedirlo, tranne che per usare un altro compilatore / linguaggio (che di solito non è un'opzione praticabile).

Ci sono molte ragioni oltre a quelle relative alla sicurezza per esaminare l'ultimo binario. O per mezzo di un debugger, un disassemblatore o un profiler ed emulatore come Valgrind (che può verificare vari aspetti di un programma compilato).

La sicurezza e la correttezza del programma di solito vanno di pari passo.

Per me è il primo che linting il codice (cioè usando PCLINT), quindi costruisci i binari, verificandoli con un fuzzer e memcheck (di Valgrind) e questo mi ha dato ottimi risultati quando si tratta di robustezza e affidabilità. Solo PCLINT in questo caso ha accesso al codice sorgente.

L'analisi del codice binario e del codice sorgente offre punti di vista leggermente diversi e pertanto è necessario applicarli entrambi. Tuttavia, l'analisi binaria può intimidire gli umani. Non direi che l'analisi a livello di codice sorgente non può essere frustrante, ma analizzare le logiche dell'applicazione a livello di assembly non è la scelta migliore. All'analisi binaria hai a che fare con ciò che accade di fatto e non può essere altrimenti. Se nel codice sorgente è possibile fare alcune ipotesi, ecco lo stato definito.

Tuttavia, test come fuzzing dovrebbero essere eseguiti contro un'applicazione compilata per garantire la robustezza dell'applicazione almeno a un certo livello. La copertura del codice dipende dalla metodologia di fuzzing, dalle specifiche dell'applicazione e da alcuni altri fattori: troppo da spiegare qui, è arte del fuzzare. Anche Microsoft sviluppa strumenti per la fuzzing e li applica in SDL . Ecco un documento di Codenomicon come intuizione di un processo: link

C'è un punto a cui AviD ha alluso ma che probabilmente dovrebbe essere enfatizzato, e cioè che la revisione del codice tende ad essere un processo molto più lungo e impegnativo rispetto alla revisione binaria. In particolare con il C ++ il binario è molto difficile anche per il professionista della sicurezza medio, per non parlare dello sviluppatore medio.

Per le lingue interpretate questo non è il caso. Il bytecode Java e .NET di Unobfuscated può essere trasformato in qualcosa di abbastanza leggibile.