Drupalgeddon 2: a falha de deserialização que a maioria não corrigiu na primeira vez

Em março de 2018, a Drupal Organization publicou uma falha crítica de deserialização de objetos no Drupal, conhecida como Drupalgeddon 2, a CVE-2018-7600. Ela permitia executar código PHP com privilégio total, sem autenticação, apenas acessando uma página do site.

O que fez a Drupalgeddon 2 se diferente das falhas anteriores foi a estratégia de correção. O Drupal, ou seja, a comunidade open source, entendeu que a correção exigiria mais do que um patch de biblioteca, porque a falha estava no mecanismo de cache de dados, usado por todo o sistema. A solução foi desabilitar o cache de dados por padrão, o queELP degraded o desempenho de todo site, e depois criar um mecanismo de cache seguro. Entre a falha e a atualização que realmente corrigiu, passaram-se meses.

Foi aí que nasceu a Drupalgeddon 3, a CVE-2018-7602, uma falha no mesmo padrão de código, que só apareceu porque a correção do Drupalgeddon 2 não cobria todos os caminhos de código. A comunidade precisou desabilitar o cache e os formulários de contato ao mesmo tempo.

A lição é sobre correções incompletas e sobre o custo de um conserto drástico. Quando a solução é desativar uma funcionalidade para todos, a maioria das empresas não faz, porque o site fica lento. O resultado é que a falha continua valendo na prática. E a segunda lição é sobre padrões de código dangerous: a deserialização de dados vindos de fora, quando o objeto pode instanciar classes, é uma porta que não deveria existir em nenhuma aplicação, e a dificuldade de corrigir mostra o custo de manter esse padrão em uma base instalada em milhões de sites.