<p>évasion du bac à sable virtualenv</p>

CVE-2018-17793 a été affecté à ce problème (pas demandé par moi).

Pourriez-vous s'il vous plaît expliquer l'impact sur la sécurité ici ? Appeler bash pour revenir au shell normal ne me semble pas être une vulnérabilité. Je ne pense pas que quiconque ait eu l'impression que virtualenv vous permet d'exécuter en toute sécurité des commandes shell non fiables, ce n'est pas pour cela.

J'ai demandé à MITRE de refuser le CVE

Normal comme suit :
(test_env) r0ot#python $(sh 1>&2)
(test_env) r0ot#
(test_env) r0ot#python
Python 2.7.15 (par défaut, 1er mai 2018, 05:55:50)
[GCC 7.3.0] sur linux2
Tapez "aide", "droit d'auteur", "crédits" ou "licence" pour plus d'informations.

importer le système d'exploitation
os.system("$(sh 1>&2)")
(test_env) r0ot#
Si vous exécutez un code malveillant :
(test_env) r0ot#python $(bash >&2)
r0ot#
POC :
(test_env) r0ot#python
Python 2.7.15 (par défaut, 1er mai 2018, 05:55:50)
[GCC 7.3.0] sur linux2
Tapez "aide", "droit d'auteur", "crédits" ou "licence" pour plus d'informations.
importer le système d'exploitation
os.system("$(bash >&2)")
r0ot#

Si vous exécutez un code malveillant

Oui, et si vous sautez d'un bâtiment, vous risquez de heurter quelque chose en descendant. Cela n'a pas vraiment d'importance puisque vous avez déjà de gros ennuis en sautant pour commencer.

PYTHON dans le bac à sable n'est pas sécurisé à 100 % et des vulnérabilités peuvent entraîner le contournement de la protection du bac à sable. Quelles sont les raisons d'utiliser le bac à sable ?
Si le bac à sable est difficile à réparer, il est recommandé d'éviter les risques dans le code et d'être invité dans la description du bac à sable.

@BakedPotato999 Python dans le "bac à sable" virtualenv est sécurisé à 0%; il n'est ni conçu pour ni ne fournit de protection contre les codes malveillants. Vous semblez très confus quant à l'objectif de virtualenv.

@BakedPotato999 Python dans le "bac à sable" virtualenv est sécurisé à 0%; il n'est ni conçu pour ni ne fournit de protection contre les codes malveillants. Vous semblez très confus quant à l'objectif de virtualenv.

Je pense que les applications exécutées dans ce Virtualenv sont indépendantes et n'affecteront pas votre système d'exploitation existant. La fermeture du bac à sable restaurera toutes les opérations. Avec le bac à sable, vous pouvez tester des programmes et des logiciels qui pourraient être risqués. Est-ce correct?

Non, complètement faux. Le but d'un virtualenv est de vous permettre d'utiliser un interpréteur Python spécifique et un ensemble de packages Python (au lieu des packages installés par le système et le répertoire utilisateur) pour exécuter des programmes dans un environnement par ailleurs normal.

Le "bac à sable", tel qu'il est, ne devrait par défaut pas inclure les packages système et utilisateur, uniquement ceux installés dans le fichier virtualenv. Mais rien ne vous empêche, par exemple, de modifier sys.path pour rétablir le système par défaut ou les packages utilisateur.

Rien ne devrait non plus vous empêcher de le faire. L'interpréteur Python dans un virtualenv devrait être capable d'effectuer toutes les opérations que l'interpréteur Python du système (le cas échéant) peut effectuer lorsqu'il est exécuté par le même utilisateur. Faire autrement briserait de nombreuses utilisations courantes et attendues d'un virtualenv.

@BakedPotato999 virtualenv/bin/activate met simplement l'exécutable Python dans l'environnement virtuel plus tôt dans votre chemin. Il n'est pas conçu pour la sécurité.

Je vais fermer ça comme invalide.

Je me demande juste comment en êtes-vous arrivé à ce que virtualenv soit un sandbox @BakedPotato999 ?

J'ai cherché dans la documentation, github et avec un git grep et la seule occurrence sandbox est celle-ci :

James Gardner a écrit un tutoriel sur l'utilisation de virtualenv avec des pylônes.

qui renvoie à http://wiki.pylonshq.com/display/pylonscookbook/Using+a+Virtualenv+Sandbox (qui a sandbox dans l'url).

Au fait, l'url est morte et c'est ici https://github.com/pypa/virtualenv/blob/384c8d13490f171a7ad99eeedd7fe45021a83d87/docs/index.rst

;).

Le fait qu'il existe maintenant "exploit" https://www.exploit-db.com/exploits/45528/ et que les trackers de sécurité des principales distributions traitent cela comme une vulnérabilité est plutôt amusant.

Je suppose que nous pourrions peut-être l'utiliser comme une escalade de privilèges, je vais l'essayer en fait

0jour confirmé ! :RÉ

Très amusant, ha ha et tout ça, mais vu qu'un CVE a été créé pour
ceci et plusieurs autres trackers le répertorient également, il atteint maintenant le
point de perdre un temps important qui devrait être consacré à la sécurité réelle
en d'autres termes, nous avons maintenant une sorte de DoS sur notre sécurité
Infrastructure. Alors mettons ça au lit maintenant s'il te plait : cette "évasion bac à sable"
n'est pas une vulnérabilité.

@0cjs Je viens de prouver qu'il peut être utilisé pour obtenir un accès root, en quoi n'est-ce pas une vulnérabilité?

1. Je ne vois pas de preuve dans votre capture d'écran que vous avez utilisé quoi que ce soit lié à virtualenv pour obtenir un accès root. Il est un peu suspect qu'il mentionne également ce qui semble être une installation de Ruby Version Manager dans le répertoire personnel de root , bien qu'il existe des explications compatibles avec un véritable exploit.
2. Je ne peux pas penser à un mécanisme plausible pour faire ce que vous avez fait en dehors de l'exploitation de quelque chose en dehors de virtualenv, car virtualenv n'a pas et n'utilise pas de fichiers suid ou similaires, ni à aucun moment il n'assume les privilèges d'un utilisateur autre que celui qui l'exécute. (Je ne dis pas que le mécanisme n'existe pas, mais vous devez fournir au moins une indication de l'endroit où ce problème pourrait être. Si vous l'avez signalé de manière responsable, vous devez le dire et à qui vous l'avez signalé. l'a signalé.)

Une explication plausible de ce qui précède est que les lignes masquées dans votre capture d'écran incluent sudo -s et une invite de mot de passe. Cela, avec une installation RVM partiellement supprimée pour l'utilisateur root, produirait exactement cette sortie, sans rien exploiter du tout.

@0cjs Je l'ai en fait effacé parce que cela fonctionnait, je teste toujours pour m'assurer que ce n'était pas à cause de mon système obsolète, je suis en fait d'accord pour dire qu'il s'agissait d'un autre exploit du noyau qui s'est révélé dans virtualenv, une fois encore tester encore.

Eh bien, vous devriez confirmer un peu plus les choses avant de signaler des outils qui, par conception, vous permettent d'exécuter des programmes et du code arbitraires en tant qu'utilisateur actuel. Signaler cela comme une vulnérabilité virtualenv est à peu près aussi logique que de le signaler comme une vulnérabilité Bash car vous avez également utilisé Bash ci-dessus, ou une vulnérabilité GCC car elle a été utilisée pour compiler du code que vous avez exécuté à un moment donné.

Je n'ai rien signalé...?

root @kali :~/test_env#python $(bash >&2)

Wow, c'est bien, mais vous n'avez pas vraiment besoin d'utiliser $()... vous pourriez juste...

root@kali :~/test_env#echo "c'est du charlatanisme"

pour "contourner" les mécanismes de sandboxing de virtualenv.

@BakedPotato999 vous avez réussi à passer de l'exécution de code python arbitraire (ou autre) en tant que root... à l'exécution de code python arbitraire (ou autre) en tant que root. Que suggérez-vous comme problème de sécurité qui surgit de la première situation à la seconde ?

Woah, quel problème sérieux. Comment puis-je utiliser un logiciel destiné à faire une chose s'il ne peut pas faire autre chose en toute sécurité ? S'il vous plaît donnez votre avis.

@ednix liveoverflow ?

@ednix Vous ne pouvez pas. Vous ne devez plus jamais utiliser un shell Unix car il ne peut pas être utilisé en toute sécurité à _certaines_ fins.

En fait, n'utilisons plus jamais d'ordinateurs. Les choses dangereuses qu'ils sont, ils peuvent être utilisés à de nombreuses fins.

En fait, ce "problème" m'a rappelé qu'il pourrait être possible d'utiliser pour l'adressage https://github.com/pypa/virtualenv/issues/1334 - quelqu'un a-t-il un code POC avec lequel nous pouvons commencer ?

Nexus by Sonatype fournit un proxy pour pypi.org. Le proxy permet de mettre en quarantaine tout package avec un score de vulnérabilité supérieur à un seuil donné.

En raison de cette erreur CVE virtualenv a été mis en quarantaine. Lorsque des malentendus entraînent le dépôt de CVE, cela a un impact réel sur les utilisateurs, ainsi qu'une perte de temps et d'efforts pour les contributeurs.

Désolé si cela énonce une évidence, mais ce problème m'affecte directement.

MITRE définit le CVE sur contesté. Peut-être que vous pouvez demander à Sonatype d'honorer ces informations.

En fait, n'utilisons plus jamais d'ordinateurs. Les choses dangereuses qu'ils sont, ils peuvent être utilisés à de nombreuses fins.

Nous ne devrions pas vivre du tout, la vie est dangereuse