<p>Virtualenv Sandbox escape</p>

CVE-2018-17793 se ha asignado a este problema (no solicitado por mí).

¿Podría explicar el impacto en la seguridad aquí? Llamar a bash para volver al shell normal no me parece una vulnerabilidad. No creo que nadie tuviera la impresión de que virtualenv le permite ejecutar de forma segura comandos de shell que no son de confianza, para eso no es.

Le pedí a MITRE que rechazara el CVE

Normal como sigue:
(prueba_env) r0ot # python $ (sh 1> & 2)
(test_env) r0ot #
(prueba_env) r0ot # python
Python 2.7.15 (predeterminado, 1 de mayo de 2018, 05:55:50)
[GCC 7.3.0] en linux2
Escriba "ayuda", "derechos de autor", "créditos" o "licencia" para obtener más información.

importar sistema operativo
os.system ("$ (sh 1> & 2)")
(test_env) r0ot #
Si ejecuta código malicioso:
(prueba_env) r0ot # python $ (bash> & 2)
r0ot #
POC:
(prueba_env) r0ot # python
Python 2.7.15 (predeterminado, 1 de mayo de 2018, 05:55:50)
[GCC 7.3.0] en linux2
Escriba "ayuda", "derechos de autor", "créditos" o "licencia" para obtener más información.
importar sistema operativo
os.system ("$ (bash> & 2)")
r0ot #

Si ejecuta código malicioso

Sí, y si saltas de un edificio, podrías golpear algo en el camino hacia abajo. Realmente no importa, ya que ya estás en un gran problema desde el principio.

PYTHON en la caja de arena no es 100% seguro, y las vulnerabilidades pueden resultar en eludir la protección de la caja de arena. ¿Cuáles son las razones para usar la caja de arena?
Si la caja de arena es difícil de arreglar, se recomienda evitar riesgos en el código y que se le solicite en la descripción de la caja de arena.

@ BakedPotato999 Python en el "sandbox" virtualenv es 0% seguro; no está diseñado ni ofrece protección contra códigos maliciosos. Parece muy confundido acerca del propósito de virtualenv.

@ BakedPotato999 Python en el "sandbox" virtualenv es 0% seguro; no está diseñado ni ofrece protección contra códigos maliciosos. Parece muy confundido acerca del propósito de virtualenv.

Creo que las aplicaciones que se ejecutan en este Virtualenv son independientes y no afectarán su sistema operativo existente. Cerrar la caja de arena restaurará todas las operaciones. Con la caja de arena, puede probar programas y software que pueden ser peligrosos. ¿Está bien?

No, completamente mal. El propósito de un virtualenv es permitirle usar un intérprete de Python específico y un conjunto de paquetes de Python (en lugar de los paquetes instalados en el sistema y en el directorio de usuario) para ejecutar programas en un entorno por lo demás normal.

La "caja de arena", tal como es, no debería incluir por defecto los paquetes del sistema y del usuario, solo los instalados en virtualenv. Pero no hay nada que le impida, por ejemplo, cambiar sys.path para traer de vuelta el sistema predeterminado o los paquetes de usuario.

Tampoco debería haber nada que le impida hacer eso. El intérprete de Python en un virtualenv debería poder realizar todas las operaciones que el intérprete de Python del sistema (si corresponde) puede realizar cuando lo ejecuta el mismo usuario. Hacer lo contrario rompería muchos usos comunes y esperados de un virtualenv.

@ BakedPotato999 virtualenv/bin/activate básicamente solo coloca el ejecutable de Python en el entorno virtual antes en su ruta. No está construido para la seguridad.

Cerraré esto como inválido.

Me pregunto, ¿cómo es que virtualenv es un sandbox @ BakedPotato999 ?

Busqué en documentos, github y con git grep y la única aparición sandbox es esta:

James Gardner ha escrito un tutorial sobre el uso de virtualenv con Pylons.

que enlaza con http://wiki.pylonshq.com/display/pylonscookbook/Using+a+Virtualenv+Sandbox (que tiene sandbox en la URL).

Por cierto, la URL está muerta y está aquí https://github.com/pypa/virtualenv/blob/384c8d13490f171a7ad99eeedd7fe45021a83d87/docs/index.rst

;).

El hecho de que exista un "exploit" ahora https://www.exploit-db.com/exploits/45528/ y que los rastreadores de seguridad de las principales distribuciones traten esto como vulunerabilidad es bastante divertido.

Supongo que podríamos usar esto como una escalada de privilegios, voy a intentarlo en realidad

0 día confirmado! :D

Muy divertido, ja, ja y todo eso, pero dado que se ha creado un CVE para
este y varios otros rastreadores también lo están enumerando, ahora está llegando al
punto de perder mucho tiempo que debería dedicarse a la seguridad real
problemas, en otras palabras, ahora tenemos una especie de DoS en nuestra seguridad
infraestructura. Así que dejemos esto en la cama ahora, por favor: este "escape de la caja de arena"
no es una vulnerabilidad.

@ 0cjs Acabo de demostrar que se puede usar para obtener acceso de root, ¿cómo no es eso una vulnerabilidad?

1. No puedo ver evidencia en su captura de pantalla de que utilizó algo relacionado con virtualenv para obtener acceso de root. Es un poco sospechoso que también esté mencionando lo que parece ser una instalación de Ruby Version Manager en el directorio de inicio de root allí, aunque hay explicaciones para eso compatible con un exploit real.
2. No puedo pensar en un mecanismo plausible para hacer lo que hiciste fuera de explotar algo fuera de virtualenv, ya que virtualenv no tiene y no usa archivos suid o similares, ni en ningún momento asume privilegios de ningún usuario que no sea el que lo ejecuta. (No estoy diciendo que el mecanismo no exista, pero debe proporcionar al menos alguna indicación de dónde podría estar este problema. Si lo ha informado de manera responsable, debe decirlo y a quién lo informó.)

Una explicación plausible de lo anterior es que las líneas en blanco en su captura de pantalla incluyen sudo -s y una solicitud de contraseña. Eso, junto con una instalación de RVM parcialmente eliminada para el usuario root, produciría exactamente ese resultado, sin explotar nada en absoluto.

@ 0cjs De hecho lo

Bueno, debería confirmar las cosas un poco más antes de informar sobre las herramientas que, por diseño, le permiten ejecutar programas y códigos arbitrarios como el usuario actual. Informar esto como una vulnerabilidad virtualenv tiene tanto sentido como informarlo como una vulnerabilidad Bash porque también usó Bash anteriormente, o una vulnerabilidad GCC porque se usó para compilar un código que ejecutó en algún momento.

¿No informé nada ...?

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

Vaya, eso es bueno, pero realmente no necesitas usar $ () ... podrías simplemente ...

root @ kali : ~ / test_env # echo "esto es charlatanería"

para "pasar por alto" los mecanismos de sandboxing virtualenv.

@ BakedPotato999 logró pasar de ejecutar código arbitrario de Python (u otro) como raíz ... a ejecutar código arbitrario de Python (u otro) como raíz. ¿Qué sugieres que es un problema de seguridad que surge de la primera situación a la segunda?

Woah, qué problema tan serio. ¿Cómo puedo utilizar un software destinado a hacer una cosa si no puede hacer otra cosa de forma segura? Por favor avise.

@ednix liveoverflow?

@ednix No puedes. Nunca debe volver a utilizar un shell de Unix porque no se puede utilizar de forma segura para _algunos_ fines.

De hecho, nunca más usemos computadoras. Son cosas peligrosas, pueden usarse para muchos propósitos.

De hecho, este "problema" me recordó que es posible usarlo para abordar https://github.com/pypa/virtualenv/issues/1334 : ¿alguien tiene algún código POC con el que podamos comenzar?

Nexus de Sonatype proporciona un proxy para pypi.org. El proxy permite poner en cuarentena cualquier paquete con una puntuación de vulnerabilidad por encima de un umbral determinado.

Debido a este error CVE virtualenv se ha puesto en cuarentena. Cuando los malentendidos dan como resultado la presentación de CVE, esto tiene un impacto real en los usuarios, así como una pérdida de tiempo y esfuerzo de los contribuyentes.

Lo siento si eso es lo obvio, pero este problema me está afectando directamente.

MITRE estableció el CVE en disputado. Quizás puedas hacer que Sonatype respete esta información.

De hecho, nunca más usemos computadoras. Son cosas peligrosas, pueden usarse para muchos propósitos.

No deberíamos vivir en absoluto, la vida es peligrosa