Brecha de segurança no Ruby on Rails exige providência imediata

Enviado por Jackson Laskoski (jacksonlaskoskiΘgmail·com):

“O governo holandês tirou do ar um serviço on-line que realizava a identificação dos cidadãos para lidar com uma brecha grave que foi corrigida na tecnologia “Ruby on Rails”. O problema ficou desconhecido e aberto durante anos, sendo corrigido somente nesta terça-feira (8). Segundo os desenvolvedores, “todas” as versões do Ruby on Rails possuem a vulnerabilidade, o que significa que a falha existe há pelo menos cinco anos, podendo ter existido já na primeira versão do software, lançada em 2005.

A brecha existente na tecnologia permite a um invasor enviar dados especiais para uma página programada em Ruby on Rails para que ela interprete os dados como um documento YAML ou símbolo do Ruby, resultando em uma execução de código na página e levando à invasão do site.

A orientação para administradores de sistemas responsáveis por aplicações que fazem uso do Ruby on Rails é imediatamente instalar as atualizações disponibilizadas. As versões corrigidas são a 3.2.11, 3.1.10, 3.0.19, e a 2.3.15. Alguns desenvolvedores têm relatado problemas nas atualizações da versão 3, afirmando que elas causam erros nas funções de troca de dados via JSON.

Não há atualização para quem ainda utiliza a primeira versão do Ruby on Rails. A recomendação, nesses casos, é imediatamente realizar uma atualização para uma versão mais nova. O site do governo holandês “DigiD”, retirado do ar para aplicar as correções necessárias, deve retomar seu funcionamento normal na manhã de quinta-feira (10).” [referência: g1.globo.com]

• Publicado por Augusto Campos em 10/01/2013 às 11:48 am
• Link direto para este post: http://br-l.org/!47904
• Siga no Twitter: @brlinuxblog e @augustocc
• Mais posts do mesmo tema: Administração

Comentários dos leitores para “Brecha de segurança no Ruby on Rails exige providência imediata”

Os comentários são responsabilidade de seus autores, e não são analisados ou aprovados pelo BR-Linux. Em algumas notícias os comentários são exibidos de forma paginada, com links abaixo do formulário de inserção de novo comentário. Leia os Termos de uso do BR-Linux.

vitor (usuário não registrado) em 10/01/2013 às 12:17 pm

Quero ver o pessoal que critica o java mandar o pessoal parar de usar ruby.

Modere: [+] [-] [fora do tema ou repetitivo] [desinformação] [troll/flame] [generalização ofensiva]
Jack em 10/01/2013 às 2:53 pm

Senhoras/Senhores,

Antes de sair “desinstalando sistemas” ou recomendando alterações bruscas, entendam de fato o contexto do bug: http://blog.codeclimate.com/blog/2013/01/10/rails-remote-code-execution-vulnerability-explained/

Nada de pânico! ;-)

Abraços!
Jack

Modere: [+] [-] [fora do tema ou repetitivo] [desinformação] [troll/flame] [generalização ofensiva]
André Moraes (usuário não registrado) em 10/01/2013 às 4:39 pm

Alguém na comunidade Rails não estudou muita coisa sobre segurança básica na web. Talvez devessem ler alguma coisa do “apostilando”…

A descrição resumida dos passos:
Parse do xml sem qualquer validação prévia do Rails (exceto sintaxe).
Parse de uma tag com código Yaml.
O código Yaml (que veio do cliente) pode ocasionar execução de código arbitrário.
O código do Yaml pode ocasionar execução de código ERB
O código ERB pode executar código Ruby com as mesmas permissões do seu processo.
Seu servidor não é mais seu….

Permitir execução arbitrária de código com base no input de usuário é D+. Se tivessem menos preguiça de escrever código, usariam alguma biblioteca que não permite esse tipo de coisa.

Modere: [+] [-] [fora do tema ou repetitivo] [desinformação] [troll/flame] [generalização ofensiva]
André Moraes (usuário não registrado) em 10/01/2013 às 4:43 pm

Mais um motivo para nunca rodar os processos como root.

Modere: [+] [-] [fora do tema ou repetitivo] [desinformação] [troll/flame] [generalização ofensiva]
Renato Elias (usuário não registrado) em 10/01/2013 às 9:44 pm

André Moraes, isto é uma feature para permitir deserialização de objetos direto do banco.

Como em ruby as classes são abertas vc pode alterar o código em execução, e assim voce pode alterar o objeto de request para ao inves de seguir o caminho normal, ele executar o que voce desejar.

Este bug só acontece se vc aceita um payload de xml sem validar ele. obvio conheço alguns lugares que isto pode a vir acontecer, mas eu mesmo quando fiz uma api em rails criei meu proprio validador para verificar os tipos do xml. fiz isto porque queria garantir.

Se acompanhar a thread no github eles estão discutindo sobre qual seria a melhor solução.

Modere: [+] [-] [fora do tema ou repetitivo] [desinformação] [troll/flame] [generalização ofensiva]
André Moraes (usuário não registrado) em 11/01/2013 às 9:41 am

@Renato Elias
“André Moraes, isto é uma feature para permitir deserialização de objetos direto do banco.
Como em ruby as classes são abertas vc pode alterar o código em execução, e assim voce pode alterar o objeto de request para ao inves de seguir o caminho normal, ele executar o que voce desejar.”

Eu, pessoalmente, não chamaria isso de “feature”. Deserializar objetos direto da base é muito útil. Mas permitir execução de código durante a deserialização não me parece uma “feature” útil.

Modere: [+] [-] [fora do tema ou repetitivo] [desinformação] [troll/flame] [generalização ofensiva]
Lucar (usuário não registrado) em 11/01/2013 às 6:08 pm

@Vitor

E o que você me fala sobre isso? http://idgnow.uol.com.br/internet/2013/01/11/falha-no-java-ameaca-usuarios-de-internet-banking-no-pais-alertam-experts/

Esse é o problema, aparecem 1000 tranqueiras no java e 1 no Ruby, Python ou PHP e nego vem se gabar.

Modere: [+] [-] [fora do tema ou repetitivo] [desinformação] [troll/flame] [generalização ofensiva]