it-swarm-eu.dev

Come dovrebbe essere controllata la sicurezza del codice sorgente?

Come verificare se il codice sorgente di un progetto open source non contiene contenuti dannosi? Ad esempio, in un set di file di codice sorgente con complessivamente 30.000 righe, potrebbero esserci 1-2 righe contenenti un'istruzione dannosa (ad es. Chiamando curl http://... | bash).

Tali progetti non sono ben noti e non si può presumere che siano ben mantenuti. Pertanto, la sicurezza di riutilizzare il loro codice sorgente del progetto non può semplicemente basarsi sulla fiducia cieca (mentre dovrebbe essere ragionevole supporre che sarebbe sicuro scaricare, verificare, compilare ed eseguire direttamente cmake direttamente, non suona buono per usare ciecamente una libreria arbitraria ospitata su GitHub).

Qualcuno mi ha suggerito di filtrare il codice sorgente e rimuovere tutti i caratteri non ASCII e invisibili (tranne alcuni banali come le interruzioni di riga). Quindi aprire ogni file con un editor di testo e leggere manualmente ogni riga. Ciò richiede tempo, richiedendo la massima attenzione quando leggo il codice e in realtà è soggetto a errori.

In quanto tale, sto cercando metodi generali per gestire questo tipo di situazioni. Ad esempio, sono disponibili strumenti standard? Qualcosa a cui devo prestare attenzione se devo davvero leggere manualmente?

40
tonychow0929

Esistono approcci automatici e manuali.

Per quanto riguarda l'automazione, potresti iniziare con lgtm - un analizzatore di codice statico gratuito per progetti open source e passare a soluzioni SAST più complesse.

Per il manuale, potresti creare un modello di minaccia della tua app ed eseguirlo attraverso OWASP ASVS elenco di controllo a partire dalle sue parti più critiche. Se è presente la cancellazione dei file nel modello di minaccia, basta chiamare qualcosa del genere: grep -ir 'os.remove('.

Naturalmente è meglio combinarli entrambi.

22
odo

Lo fai da solo o ti fidi di qualcun altro

Come con la maggior parte delle cose nella vita, devi farlo da solo o fidarti di qualcun altro. Qui la fiducia copre sia la mancanza di intenzioni dannose sia la competenza sufficiente per eseguire correttamente l'attività.

Ad esempio, potresti presentare le tue tasse te stesso o affidare un consulente fiscale per farlo (chi non solo non deve tentare di frodare, ma sa anche come presentare le tasse!).

Se sei un'azienda, farlo da solo verrà effettivamente eseguito da uno o più dipendenti, che a loro volta devono essere considerati affidabili.

La terza parte di cui ti fidi, non deve nemmeno essere una sola persona. Potrebbe essere il Microsoft Windows Development Team o gli sviluppatori core di Wordpress .

Per quanto riguarda la sicurezza del codice sorgente, si desidera che l'esperto non solo sia ben intenzionato, ma anche esperto nel codificare il programma in modo sicuro/trovare eventuali problemi di sicurezza che potrebbero esserci.

(oltre ad alcuni sistemi di frontiera aggiuntivi se trattati nel loro insieme, ad esempio, si desidera che il loro codice non sia stato compromesso mentre lo hanno caricato nel repository o l'e-mail del proprio dipendente in cui si afferma che i risultati vengono sostituiti da un hacker dannoso all'interno della propria rete dire che l'applicazione andava bene)

Dovrai valutare le tue opzioni, valutare il rischio associato a ciascuna e scegliere il percorso più adatto ai tuoi interessi (e al tuo budget!).

Se dovessi verificare la sicurezza del codice sorgente di un blog che utilizza Wordpress, in genere mi fiderei che il codice originale andava bene1¹ e controllare le differenze tra la versione ufficiale e quella usata. Se il sito Web fosse compromesso, sarebbe molto più facile scoprirlo.

¹ Ovviamente controllando il log delle versioni successive se ne utilizzava uno obsoleto.

Tuttavia, se fosse stato sviluppato dal nipote del proprietario, mi sarei aspettato di trovare molte vulnerabilità lì e raccomanderei un controllo approfondito di tutto.

Nel tuo caso, dovresti valutare il rischio e il costo dello sviluppo dell'equivalente di quella libreria (tieni presente che la possibilità di problemi nel tuo prodotto interno non è pari a zero e dipenderà, tra l'altro, dalla qualità di le persone coinvolte) rispetto al rischio e al costo dell'auditing e dell'utilizzo di tale libreria.

Ora, potrebbero esserci fattori attenuanti che semplificano l'auditing. Ad esempio, se il codice non attendibile può essere eseguito in una macchina virtuale isolata, ciò potrebbe essere sufficiente per non aver bisogno di ulteriori verifiche (anche qui, ti stai fidando dell'implementazione VM). Oppure può essere considerata sufficiente per controllare le parti di quel programma eseguite come root.

Per l'auditing di una libreria, gli analizzatori di codice possono aiutare a sottolineare le parti problematiche (come sottolineato), ma per considerarlo pulito avrei effettivamente qualcuno che leggesse e capisse il codice, anche se superficialmente.

Ad esempio, la possibilità di rimuovere file arbitrari non è dannosa di per sé . Devi capire il programma per sapere se ha senso.

Ancora una volta, è una questione di minacce e rischi per quello che stai facendo. Se ti preoccupi solo della libreria che sta esfiltrando i dati, filtrare le connessioni al firewall potrebbe essere sufficiente. Se ti preoccupi che la libreria elimini file importanti (e per qualche strana ragione non puoi negare tale autorizzazione), potresti semplicemente scorrere un gruppo di codice che eseguiva solo calcoli matematici. Se quella libreria calcola i parametri per il lancio di un razzo ... beh, è ​​meglio assicurarsi che anche quei calcoli siano corretti!

20
Ángel

Usa un servizio

Esistono servizi professionali come Black Duck e Whitesource che controllano le dipendenze open-source.

3
DawnPaladin

Se usi il codice di qualcun altro, sei più o meno in balia dei meccanismi di integrità forniti dai manutentori, questo vale per tutto il software, non solo per l'open source.

Sia per il software open source commerciale che per il pacchetto (ad es. Rpm, deb ecc.) La firma del codice è comune: ciò dimostra che hai ricevuto è ciò che il firmatario intendeva ricevere.

Nel caso del codice sorgente, vengono solitamente utilizzati checksum. Ma questo ha poco valore a meno che il checksum non sia accessibile da una fonte diversa dal codice sorgente.

Si noti che questi hanno solo lo scopo di proteggere da un attacco di tipo MITM sull'applicazione.

usare una libreria arbitraria ospitata su GitHub

... nel qual caso tutti i file/versioni hanno un hash pubblicato su Github - per sovvertire questo, un utente malintenzionato dovrebbe sovvertire Github stesso o l'account Github del manutentore - Posso eseguire il fork di qualsiasi cosa su Github ma viene quindi attribuito a me e il repository originale non sono interessati a meno che il manutentore accetti le mie richieste pull. Potresti avere più fiducia nell'integrità di Github rispetto ai manutentori del codice, nel qual caso sarebbe ragionevole fidarsi di un hash pubblicato nello stesso posto del codice sorgente.

Nessuno di questi meccanismi fornisce protezione contro il malware che è stato iniettato prima dell'applicazione della verifica di integrità.

Se hai accesso al codice sorgente, hai la possibilità di esaminare il codice (che è molto più facile che esaminare gli eseguibili) e ci sono strumenti automatizzati per farlo come quelli suggeriti da Odo.

2
symcbean

Gli analizzatori statici non funzioneranno sempre

Controlla os.remove In qualsiasi punto del codice non funzionerà su tutti gli attaccanti, poiché alcuni potrebbero semplicemente fare eval("os" + ".remove"). È possibile creare regex anche più avanzati, ma l'attaccante può sempre rendere il proprio codice più complicato, caso per caso:

x = "r"
eval("os." + x + "emove")

Più teoricamente, a causa del problema di arresto, è impossibile controllare tutti i potenziali stati per vedere se viene invocata una chiamata di sistema pericolosa.

Un utente malintenzionato può evitare abbastanza facilmente gli analizzatori di codice statico creando un piccolo interprete per un linguaggio personalizzato che esegue le operazioni dannose.

Esecuzione del codice all'interno di un container/honeypot

Tutto il software alla fine interagisce con il sistema operativo. Eseguendo il software all'interno di un container o honeypot con strace o uno strumento simile, puoi vedere quali informazioni il programma o la libreria sta tentando di raccogliere.

Il programma tenta di capire se è in esecuzione all'interno di un contenitore? Legge i file che non dovrebbe o addirittura li modifica? Quindi potresti avere un software dannoso.

Questo non funzionerà sempre, potrebbe essere necessaria qualche ispezione manuale

Alcuni codici dannosi si attivano solo in date specifiche, ma almeno vedrai che si accede a questo. Da lì puoi verificare dove nel codice questo accade e perché.

1
Ultimate Hawk