Quelles mesures de sécurité prend PyPI et les référentiels de logiciels tiers similaires?
PyPI est un référentiel logiciel tiers pour les packages Python. Tout le monde peut y télécharger des packages (voir The Python Index de package (PyPI)) ==).
- Comment PyPI empêche-t-il les gens de télécharger des logiciels malveillants?
- Lorsque je recherche un logiciel, comment puis-je être (plus) sûr qu'il ne s'agit pas d'un logiciel malveillant?
- Que puis-je, en tant que développeur de packages, faire pour que les autres se sentent plus en sécurité en utilisant mes packages?
- Existe-t-il des exemples "historiques" de logiciels malveillants dans les référentiels? Combien de mal ont-ils fait?
J'ai posé la question pour PyPI, mais je serai également intéressé par des référentiels similaires comme npm (JavaScript) ou composer (PHP) .
J'ai posé cette question pour CTAN (tex) dans le chat tex.SE. La réponse est qu'il n'y a pas de mesures de sécurité. Ils font confiance aux personnes/développeurs pour ne pas télécharger de logiciels malveillants.
J'ai écrit un blog post sur ce sujet récemment.
Pour répondre à vos points:
Comment PyPI empêche-t-il les gens de télécharger des logiciels malveillants?
Ce n'est pas le cas. Tout Python peut être téléchargé. L'exécution de code arbitraire est possible lors de l'installation du package. Auditez soigneusement vos dépendances.
Lorsque je recherche un logiciel, comment puis-je être (plus) sûr qu'il ne s'agit pas d'un logiciel malveillant?
Téléchargez l'archive et regardez le code.
Que puis-je, en tant que développeur de packages, faire pour que les autres se sentent plus économisés en utilisant mes packages?
Si vos utilisateurs vous font confiance, PyPI fonctionne parfaitement bien. Les packages sont servis via HTTPS et des sommes de contrôle sont disponibles pour vérifier.
Existe-t-il des exemples "historiques" de logiciels malveillants dans les référentiels? Combien de mal ont-ils fait?
Je ne connais aucun exemple historique, mais je peux facilement télécharger un package de démonstration. PyPI ne fait rien pour empêcher cela. Il agit comme un simple index de packages Python, il appartient aux utilisateurs de faire confiance aux développeurs.
Il existe deux modèles de menace ici:
- Développeur malveillant téléchargeant des packages malveillants
- Un attaquant malveillant téléchargeant des packages malveillants appartenant à des développeurs légitimes
PyPI ne fait aucune tentative pour essayer de résoudre # 1. L'audit du code avant les installations et uniquement l'installation de packages provenant de développeurs réputés sont la seule "protection" que vous ayez contre ces derniers. Si vous avez trouvé un package malveillant, vous pouvez le signaler aux responsables PyPI et le package sera probablement supprimé. Mais en réalité, il n'y a aucune protection contre cela, car les packages PyPI ne sont pas validés avant d'être disponibles pour les installations.
Sur le deuxième modèle de menace, il existe un certain nombre de mesures de sécurité. Une version plus récente de PyPI télécharge les packages via HTTPS, et les packages peuvent éventuellement être signés GPG . Il y a des propositions pour implémenter theupdateframework (tuf) , bien que je ne sache pas jusqu'où ils sont allés.
L'installation sur vos packages utilisateur ou virtualenv peut limiter les dommages que peut avoir un package malveillant, en limitant le programme d'installation à ne pas utiliser Sudo pendant l'installation. Mais ne vous y fiez pas trop.
Pour autant que je sache, en général, il existe des garanties très limitées concernant le code disponible dans les référentiels de code en ligne (par exemple rubygems, npm, nuget, PyPI, etc.). Dans de nombreux cas, ils ne prennent pas en charge ou n'appliquent pas des éléments tels que le code signé ou d'autres mesures de sécurité basées sur l'intégrité et l'authentification auprès des sites à déployer n'est, dans certains cas, qu'une combinaison nom d'utilisateur/mot de passe, de sorte que vous ne dépendez pas seulement de les développeurs ne placent pas délibérément des logiciels malveillants dans leur code mais également que ces développeurs ont de bonnes pratiques de sécurité opérationnelle.
Un problème encore plus important est que dans de nombreux cas, les bibliothèques que vous installez ont des dépendances, dans certains cas un grand nombre de dépendances, vous êtes donc sûr que les développeurs de ces dépendances ne sont pas malveillants et ont de bonnes pratiques de sécurité.
Comme Terry le dit avec de nombreuses bibliothèques de code, il existe des crochets pour exécuter du code arbitraire lors de l'installation (avant même que la bibliothèque ne soit utilisée), donc le simple fait d'installer peut avoir de mauvaises conséquences, surtout s'il est effectué en tant qu'utilisateur privilégié.
En termes d'instances historiques de compromis, il y avait bien le compromis Rubygems en 2013 comme exemple d'un référentiel attaqué.
Pour résoudre le problème, il y a l'initiative pdate Framework pour essayer d'améliorer la situation.