Quali misure di sicurezza prendono PyPI e repository di software di terze parti simili?

Question

Quali misure di sicurezza prendono PyPI e repository di software di terze parti simili?

#1 da (12 voti)
#2 da (10 voti)
#3 da (4 voti)

25

PyPI è un repository software di terze parti per pacchetti Python. Tutti possono caricare pacchetti su di esso (vedi Python Package Index (PyPI) ).

In che modo PyPI impedisce alle persone di caricare malware?
Quando cerco software, come posso essere (più) sicuro che non sia malware?
Che cosa posso fare, come sviluppatore di pacchetti, per far sentire gli altri più sicuri usando i miei pacchetti?
Esistono esempi "storici" di malware nei repository? Quanto danno hanno fatto?

Ho fatto la domanda per PyPI, ma sarei interessato anche a repository simili come npm (JavaScript) o < a href="https://packagist.org/"> compositore (PHP) .

Ho posto questa domanda per CTAN (tex) nella chat tex.SE. La risposta è stata che non ci sono misure di sicurezza. Si fidano delle persone / sviluppatori a non caricare malware.

source-code malware programming anomaly-detection

posta Martin Thoma 16.01.2015 - 14:23

fonte

3 risposte

Leggi altre domande sui tag source-code malware programming anomaly-detection

Come posso essere protetto dalle vulnerabilità delle immagini? CSRF con JSON POST

score 12 · Answer 1

In realtà ho scritto di recente un post sul blog su questo argomento.

Per rispondere ai tuoi punti:

How does PyPI prevent people from uploading malware?

Non è così. Qualsiasi codice Python può essere caricato. L'esecuzione di codice arbitrario è possibile durante l'installazione del pacchetto. Controlla attentamente le tue dipendenze.

When I am searching for software, how can I be (more) sure that it is not malware?

Scarica il tarball e guarda il codice.

What can I, as a developer of packages, do to make others feel more save using my packages?

Se i tuoi utenti si fidano di te, PyPI funziona perfettamente. I pacchetti vengono offerti su HTTPS e i checksum sono disponibili per la verifica.

Are there "historic" examples of malware in the repositories? How much harm did they do?

Non sono a conoscenza di esempi storici, ma posso facilmente caricare un pacchetto demo. PyPI non fa nulla per impedirlo. Agisce come un semplice indice dei pacchetti Python, è compito degli utenti di cui si fidano gli sviluppatori.

score 10 · Answer 2

Qui ci sono due modelli di minacce:

Sviluppatore malevolo che carica pacchetti dannosi
Attentatore malintenzionato che carica pacchetti dannosi che appartengono a sviluppatori legittimi

PyPI non tenta di risolvere il # 1. Il codice di controllo prima delle installazioni e l'installazione di pacchetti solo da sviluppatori stimabili sono l'unica "protezione" che si ha contro di essi. Se hai trovato un pacchetto malevolo, puoi segnalarlo ai manutentori di PyPI e il pacchetto verrà probabilmente rimosso. Ma efficacemente, non c'è protezione contro di esso in quanto i pacchetti PyPI non sono pre-controllati prima che siano disponibili per le installazioni.

Nel secondo modello di minaccia, ci sono un certo numero di misure di sicurezza. La versione più recente di PyPI scarica i pacchetti su HTTPS ei pacchetti possono essere eventualmente firmati GPG . Ci sono proposte per implementare theupdateframework (tuf) , anche se non so fino a che punto sono andati.

L'installazione sui pacchetti utente o virtualenv può limitare i danni che il pacchetto dannoso può avere, limitando il programma di installazione a non utilizzare sudo durante l'installazione. Ma non fidarti troppo.

score 4 · Answer 3

Per quanto ne so, in generale ci sono garanzie molto limitate sul codice disponibile dai repository di codici online (ad esempio rubygems, npm, nuget, PyPI, ecc.). In molti casi non supportano o applicano elementi come il codice firmato o altre misure di sicurezza basate sull'integrità e l'autenticazione ai siti da implementare è, in alcuni casi, solo una combinazione di nome utente / password, quindi non sei dipendente solo gli sviluppatori non inseriscono deliberatamente malware nel loro codice ma anche che quegli sviluppatori hanno buone pratiche di sicurezza operativa.

Un problema ancora più grande è che in molti casi le librerie installate hanno delle dipendenze, in alcuni casi un gran numero di dipendenze, quindi ci si può fidare che anche gli sviluppatori di queste dipendenze non siano dannosi e abbiano buone pratiche di sicurezza.

Come dice Terry con molte librerie di codice ci sono ganci per eseguire codice arbitrario durante l'installazione (prima che la libreria sia usata anche), quindi solo l'atto di installazione può avere conseguenze negative, specialmente se fatto come utente privilegiato.

In termini di istanze storiche di compromesso, bene c'è stato il compromesso Rubygems in 2013 come esempio di un repository attaccato.

In termini di risoluzione del problema, ecco l'iniziativa Update Framework per provare a migliorare la situazione.