Sono stati condotti studi di casi su vulnerabilità intenzionali o malware in progetti open source?

Question

Sono stati condotti studi di casi su vulnerabilità intenzionali o malware in progetti open source?

#1 da (2 voti)

3

Nella mia esperienza, è un mantra comune che l'open source tende ad essere sicuro grazie alla sua disponibilità per un controllo aperto. Tendo ad essere d'accordo con questo. Allo stesso tempo non è un segreto che le vulnerabilità vengono costantemente scoperte.

Inoltre, ritengo sia facile immaginare che gli sviluppatori molto entusiasti ottengano librerie e strumenti e che siano disponibili in vari repository. Credo che queste risorse vengano regolarmente frettolosamente utilizzate per la sperimentazione e talvolta adottate in progetti più estesi senza un controllo accurato (forse oltre a un controllo di compatibilità delle licenze e una certa sicurezza che il set di funzionalità corrisponda a quanto desiderato)

Mi viene in mente PyPI, Dockerhub, ecc.

Vorrei sapere se ci sono molti casi documentati di cose come:

Contributi dannosi di successo a software open source prevalente
Progetti più piccoli che sono apparsi che potrebbero essere considerati malware con il pretesto di fornire alcune funzionalità semplici ma accattivanti
Rapporti di gioco scorretto sui contributi tentati

Capisco che essere i migliori progetti FOSS abbia manutentori di alta qualità, ma vedo anche questo mondo attuale di spamming ininterrotto, phishing, spearphishing, furto d'identità e governi aggressivi. Personalmente ho difficoltà a credere che i cattivi attori si prenderebbero mai una pausa dal cercare di dare contributi malevoli a questi progetti, visto come si prendono una pausa dai loro altri cattivi compiti.

opensource

posta andyortlieb 17.12.2016 - 05:36

fonte

1 risposta

Leggi altre domande sui tag opensource

Esistono noti virus di sottaceti Python? Il modo corretto per convalidare gli input dell'utente

score 2 · Answer 1

Anche se la tua domanda è ben strutturata e specifica, le risposte a queste tendono a rasentare il lato della generazione di discussioni. Cercherò di risponderti il più direttamente possibile.

Successful malicious contributions to prevalent open source software

Non sembra esserci molto nel modo di prove documentate di questo. Sicuramente è successo, ma a causa della natura stessa di OpenSource, dove chiunque abbia una certa conoscenza può presentare una richiesta di aggiornamento del codebase ci sarà sempre la domanda se qualcosa che finisce per essere malizioso sia intenzionale o semplicemente un errore. La vulnerabilità di Heartbleed in OpenSSL è passata inosservata per 2 anni, ma alla fine è stata segnalata come un errore dall'utente che ha caricato la modifica e l'amministratore che l'ha approvata.

Reports of foul play on attempted contributions

Indietro nel 2003 , c'era un tentativo da parte di un aggressore sconosciuto di forzare una backdoor nel kernel di Linux. Hanno sfruttato le pratiche di controllo delle sorgenti al momento per inserire il codice direttamente in un repository di codice secondario piuttosto che tentare di inviare il codice per la revisione tra pari.

Dato che chiunque può richiedere una modifica al codice OpenSource, ci sarà una quantità enorme di casi di gioco scorretto - Tranne tutto il dramma e le notizie di questo accadimento saranno all'interno delle bacheche dei messaggi e di altre comunità per questo Software. Il tipo che stai cercando - i casi segnalati per i notiziari sono molto meno probabili. Se l'applicazione è abbastanza grande da essere segnalata, allora ci sono molte fasi di approvazione per rivedere prima il codice.

Più l'applicazione diventa grande e più gli occhi "potenziali" sul codice diventano. Come hacker, se invii un codice dannoso in un controllo sorgente basato su revisioni paritetiche come Github, vai all-in e dici " spero che non lo stia esaminando a fondo, perché sto provando a fai qualcosa di cattivo '. Sarebbe molto più sicuro e meno probabile per te essere catturato (immediatamente, comunque) per cercare di ottenere il tuo codice malevolo in altri modi che non saranno sottoposti ad auditing come un attacco Man-in-the-Middle che schiera una versione modificata dell'applicazione a qualcuno che sta cercando di scaricarlo. Avresti un maggiore controllo sull'intero code-base e sarai quindi in grado di nascondere le tue intenzioni e, come hai suggerito tu stesso, gli sviluppatori e gli utenti molto desiderosi hanno meno probabilità di confrontare le firme digitali di ciò che stanno scaricando rispetto a rover app che sono i più investiti nella sicurezza del codice.

TL; DR - Come utente malintenzionato, è più affidabile spingere il codice dannoso a un utente finale eccessivamente desideroso che sperare che gli amministratori che sono appassionati del proprio prodotto non siano in linea.