<p>Virtualenv Sandbox escape</p>

CVE-2018-17793 foi atribuído a este problema (não solicitado por mim).

Você poderia explicar o impacto na segurança aqui? Chamar o bash para voltar ao shell normal não parece uma vulnerabilidade para mim. Não creio que alguém tenha a impressão de que o virtualenv permite que você execute comandos shell não confiáveis ​​com segurança, não é para isso que serve.

Pedi ao MITER que rejeitasse o CVE

Normal da seguinte forma:
(test_env) r0ot # python $ (sh 1> & 2)
(test_env) r0ot #
(test_env) r0ot # python
Python 2.7.15 (padrão, 1º de maio de 2018, 05:55:50)
[GCC 7.3.0] no linux2
Digite "ajuda", "direitos autorais", "créditos" ou "licença" para obter mais informações.

importar os
os.system ("$ (sh 1> & 2)")
(test_env) r0ot #
Se você executar um código malicioso:
(test_env) r0ot # python $ (bash> & 2)
r0ot #
POC:
(test_env) r0ot # python
Python 2.7.15 (padrão, 1º de maio de 2018, 05:55:50)
[GCC 7.3.0] no linux2
Digite "ajuda", "direitos autorais", "créditos" ou "licença" para obter mais informações.
importar os
os.system ("$ (bash> & 2)")
r0ot #

Se você executar um código malicioso

Sim, e se você pular de um prédio, poderá bater em alguma coisa durante a queda. Realmente não importa, já que você já está em apuros desde o início.

PYTHON na sandbox não é 100% seguro e vulnerabilidades podem resultar em contornar a proteção da sandbox. Quais são os motivos para usar a sandbox?
Se a sandbox for difícil de consertar, é recomendável evitar riscos no código e ser solicitado na descrição da sandbox.

@ BakedPotato999 Python no virtualenv "sandbox" é 0% seguro; não foi projetado nem fornece proteção contra códigos maliciosos. Você parece muito confuso sobre o propósito do virtualenv.

@ BakedPotato999 Python no virtualenv "sandbox" é 0% seguro; não foi projetado nem fornece proteção contra códigos maliciosos. Você parece muito confuso sobre o propósito do virtualenv.

Acho que os aplicativos em execução neste Virtualenv são independentes e não afetarão seu sistema operacional existente. Fechar a sandbox irá restaurar todas as operações. Com a sandbox, você pode testar programas e softwares que podem ser arriscados. Isso está certo?

Não, completamente errado. O objetivo de um virtualenv é permitir que você use um interpretador Python específico e um conjunto de pacotes Python (em vez dos pacotes instalados pelo sistema e pelo userdir) para executar programas em um ambiente normal.

A "caixa de areia", tal como está, deve, por padrão, não incluir pacotes de sistema e de usuário, apenas aqueles instalados no virtualenv. Mas não há nada impedindo você de, por exemplo, alterar sys.path para trazer de volta o sistema padrão ou os pacotes do usuário.

Nada deve impedi-lo de fazer isso. O interpretador Python em um virtualenv deve ser capaz de fazer todas as operações que o interpretador Python do sistema (se houver) pode fazer quando executado pelo mesmo usuário. Fazer o contrário quebraria muitos usos comuns e esperados de um virtualenv.

@ BakedPotato999 virtualenv/bin/activate basicamente apenas coloca o executável Python no ambiente virtual anteriormente em seu caminho. Não foi construído para segurança.

Vou fechar isso como inválido.

Eu só me pergunto, como você veio com o virtualenv sendo um sandbox @ BakedPotato999 ?

Eu pesquisei nos documentos, no github e com um git grep e a única ocorrência de sandbox é esta:

James Gardner escreveu um tutorial sobre como usar o virtualenv com Pylons.

que direciona para http://wiki.pylonshq.com/display/pylonscookbook/Using+a+Virtualenv+Sandbox (que tem sandbox no url).

A propósito, o url está morto e está aqui https://github.com/pypa/virtualenv/blob/384c8d13490f171a7ad99eeedd7fe45021a83d87/docs/index.rst

;).

O fato de existir "exploit" agora https://www.exploit-db.com/exploits/45528/ e que os rastreadores de segurança das principais distros tratem isso como vulnerabilidade é bastante engraçado.

Acho que podemos usar isso como um escalonamento de privilégios, vou tentar na verdade

0 dia confirmado! : D

Muito divertido, ha ha e tudo mais, mas dado que foi criado um CVE para
este e vários outros rastreadores também estão listando-o, agora está alcançando o
ponto de desperdiçar um tempo significativo que deveria ser gasto em segurança real
problemas, em outras palavras, agora temos uma espécie de DoS em nossa segurança
a infraestrutura. Então, vamos colocar isso para dormir agora, por favor: este "escape sandbox"
não é uma vulnerabilidade.

@ 0cjs Acabei de provar que pode ser usado para obter acesso root, como isso não é uma vulnerabilidade?

1. Não consigo ver evidências em sua captura de tela de que você usou algo relacionado ao virtualenv para obter acesso root. É um pouco suspeito que ele esteja mencionando o que parece ser uma instalação do Ruby Version Manager no diretório inicial de root lá, também, embora haja explicações para isso compatível com um exploit real.
2. Não consigo pensar em um mecanismo plausível para fazer o que você fez fora de explorar algo fora do virtualenv, uma vez que o virtualenv não tem e não usa arquivos suid ou semelhantes, nem assume privilégios de qualquer outro usuário além daquele que o executa. (Não estou dizendo que o mecanismo não existe, mas você precisa fornecer pelo menos alguma indicação de onde esse problema pode estar. Se você relatou o problema de forma responsável, você precisa dizer isso, e a quem você relatou.)

Uma explicação plausível para o acima é que as linhas em branco em sua captura de tela incluem sudo -s e um prompt de senha. Isso, junto com uma instalação RVM parcialmente removida para o usuário root, produziria exatamente essa saída, sem explorar nada.

@ 0cjs Na verdade,

Bem, você deve confirmar as coisas um pouco mais antes de relatar ferramentas que, por design, permitem que você execute programas e códigos arbitrários como o usuário atual. Relatar isso como uma vulnerabilidade virtualenv faz tanto sentido quanto relatá-lo como uma vulnerabilidade Bash porque você também usou o Bash acima, ou uma vulnerabilidade GCC porque foi usado para compilar algum código que você executou em algum ponto.

Eu não relatei nada ...?

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

Uau, isso é bom, mas você realmente não precisa usar $ () ... você poderia apenas ...

root @ kali : ~ / test_env # echo "isso é charlatanismo"

para "ignorar" os mecanismos de sandbox do virtualenv.

@ BakedPotato999 você conseguiu passar da execução de código python arbitrário (ou outro) como root ... para a execução de código python arbitrário (ou outro) como root. O que você sugere que é um problema de segurança que surge da primeira situação para a segunda?

Woah, que problema sério. Como posso usar um software destinado a fazer uma coisa se não posso fazer outra coisa com segurança? Por favor informar.

@ednix liveoverflow?

@ednix Você não pode. Você nunca deve usar um shell Unix novamente porque ele não pode ser usado com segurança para _alguns_ propósitos.

Na verdade, nunca vamos usar computadores novamente. Coisas perigosas que são, podem ser usadas para muitos propósitos.

Na verdade, esse "problema" me lembrou que pode ser possível usá-lo para endereçar https://github.com/pypa/virtualenv/issues/1334 - alguém tem algum código POC com o qual possamos começar?

Nexus by Sonatype fornece um proxy para pypi.org. O proxy permite colocar em quarentena qualquer pacote com uma pontuação de vulnerabilidade acima de um determinado limite.

Devido a esse CVE equivocado, o virtualenv foi colocado em quarentena. Quando mal-entendidos resultam em CVEs sendo arquivados, isso tem um impacto real sobre os usuários, bem como desperdício de tempo e esforço do colaborador.

Desculpe se estou afirmando o óbvio, mas esse problema está me afetando diretamente.

MITER definiu o CVE como disputado. Talvez você possa fazer com que o Sonatype respeite essas informações.

Na verdade, nunca vamos usar computadores novamente. Coisas perigosas que são, podem ser usadas para muitos propósitos.

Não deveríamos viver de forma alguma, a vida é perigosa