Injeção de CRLF encontrada na popular dependência Python urllib3

Em 18 de abril de 2019, foi encontrada uma vulnerabilidade de injeção de CRLF na popular biblioteca Python urllib3. A urllib3 é um cliente HTTP para Python que inclui recursos importantes, como segurança para uso com threads, pool de conexões, verificação de SSL/TLS no cliente e muito mais. Ela é amplamente utilizada no ecossistema Python, inclusive pela requests, outra biblioteca popular. Na verdade, a urllib3 é usada por mais de 500 bibliotecas de código aberto. Se você tem um projeto Python, é muito provável que a urllib3 faça parte da sua árvore de dependências.

Nós já adicionamos a vulnerabilidade ao nosso banco de dados. Se o Snyk monitora seu projeto e detectar o pacote vulnerável, você já terá recebido nossos alertas automáticos. Caso contrário, teste gratuitamente o repositório do código da sua aplicação para verificar se ele é afetado pela versão vulnerável da urllib3.

Se você descobrir que sua aplicação Python usa a biblioteca vulnerável, aja imediatamente e atualize para a versão corrigida mais próxima, conforme sugerido pelo Snyk na sua árvore de dependências.

Vulnerabilidade de injeção de CRLF

CRLF é a sigla de “Carriage Return, Line Feed” (retorno de carro e avanço de linha), termo usado para indicar o fim de uma linha. Uma injeção de CRLF consiste em inserir uma quebra de linha na aplicação. No caso da vulnerabilidade da urllib3, um invasor que controle o parâmetro de endereço da solicitação pode manipular um cabeçalho HTTP e, em seguida, atacar um serviço interno.

A vulnerabilidade foi discutida inicialmente em um relatório do Python Bug Tracker sobre um problema semelhante nas bibliotecas urllib2/urllib (que fazem parte, respectivamente, das bibliotecas padrão do Python 2 e do Python 3). O comentarista Alvin Chang (nome de usuário alvinchang) observou que também conseguiu reproduzir o exploit na biblioteca urllib3.

Isso levou à abertura de uma issue no repositório GitHub da urllib3, e uma correção foi disponibilizada nas séries de versões 1.24.x e 1.25.x.

A prova de conceito da vulnerabilidade, publicada no Python Bug Tracker pelo usuário ragdoll e adaptada para a versão da urllib3 por alvinchang, é a seguinte.

import urllib3

pool_manager = urllib3.PoolManager()

host = "localhost:7777?a=1 HTTP/1.1\r\nX-injected: header\r\nTEST: 123"
url = "http://" + host + ":8080/test/?test=a"

try:
info = pool_manager.request('GET', url).info()
print(info)
except Exception:
pass

# nc -l localhost 7777
GET /?a=1 HTTP/1.1
X-injected: header
TEST: 123:8080/test/?test=a HTTP/1.1
Host: localhost:7777
Accept-Encoding: identity

Neste exemplo, o servidor nc exibe a solicitação HTTP com o conteúdo de cabeçalho manipulado: X-injected:header, indicando que a injeção do cabeçalho HTTP foi bem-sucedida.

Meu projeto está vulnerável?

Quer saber se seu projeto está vulnerável? Crie hoje mesmo uma conta gratuita no Snyk e verifique se há vulnerabilidades no seu projeto. O Snyk vai apresentar um relatório com todas as vulnerabilidades conhecidas nas suas dependências de código aberto — inclusive na biblioteca urllib3, caso você use uma versão afetada.

É importante entender que a biblioteca urllib3 costuma ser uma dependência indireta e pode estar instalada no seu projeto sem que você saiba. Algumas dependências diretas que usam a urllib3 não utilizam as partes vulneráveis da biblioteca. Por exemplo, no momento, tudo indica que a biblioteca requests (que inclui a urllib3 como dependência) não está vulnerável. Mas isso pode não se aplicar a todos os projetos que dependem da urllib3. Por isso, vale a pena verificar se ela está na sua árvore de dependências.

Como posso proteger meu projeto?

Se você descobrir que seu projeto usa uma versão vulnerável da urllib3, recomendamos atualizar para a versão 1.24.3 ou posterior. Essa medida também protege você contra outras vulnerabilidades encontradas na biblioteca urllib3. Também recomendamos verificar seu código em busca de ocorrências de urllib2 ou urllib (respectivamente, em projetos Python 2 e Python 3). Os exploits para essas vulnerabilidades das bibliotecas padrão ainda não foram corrigidos — por isso, é importante avaliar o risco específico para você revisando seu código.