AnyDesk no Linux: consentimento do usuário não protege o protocolo

Pesquisadores da V12 publicaram o AnyPwn, uma prova de conceito que executa comandos como root no AnyDesk Linux 8.0.2 antes da aprovação da conexão.[1] A demonstração usa conexão TCP direta à porta 7070 e depende da disposição de objetos na memória; em condições diferentes, pode apenas derrubar o serviço.[1] O problema foi corrigido no AnyDesk Linux 8.0.3, mas a nota de versão o descreveu como um erro capaz de causar crash, sem CVE nem boletim formal até a reportagem.[1]

O que muda para quem desenvolve

A principal lição de arquitetura é separar autorização da interface e segurança do protocolo. Um botão de aceitar acesso não deve ser considerado uma barreira para tudo que acontece antes dele. Ao desenhar um serviço remoto, a pergunta útil é: quanto processamento de entrada não confiável ocorre antes da decisão de acesso, e com quais privilégios?

Neste caso, a corrupção combina cálculo de tamanho em aritmética de 32 bits sem verificação de overflow e escrita fora dos limites no heap.[1] A análise que interessa ao desenvolvedor não é reproduzir a exploração, mas revisar a cadeia entre tamanho declarado, tamanho efetivamente alocado e limites da escrita. Validar cada variável isoladamente não basta se a relação entre elas ficar inconsistente.

Também vale questionar um inventário de segurança que só procura números de CVE. Minha leitura: a decisão de atualização precisa considerar avisos técnicos e mudanças relevantes no produto, não apenas a classificação comercial da nota de lançamento.

Como aplicar

Faça uma verificação operacional sem executar o exploit:

1. Identifique a versão do serviço realmente em execução, não apenas a versão do instalador guardado.
2. Se houver versão afetada, planeje atualização para pelo menos 8.0.3, que contém a correção reportada.[1]
3. Confira de quais segmentos a conexão direta é acessível e restrinja o acesso ao necessário.
4. Depois da atualização, valide o fluxo legítimo de suporte remoto e registre versão, exposição e evidência de funcionamento.

Para código próprio, proponha um teste unitário do cálculo de buffers com comprimentos próximos ao limite do tipo inteiro. O critério de aceitação deve exigir rejeição explícita quando cabeçalho e conteúdo não puderem ser somados com segurança. Isso é uma proposta de teste, não uma validação já realizada sobre o AnyDesk.

Cuidados e limites

Há divergência sobre retransmissão: a fabricante afirmou que o problema se restringe às conexões diretas no Linux, enquanto os pesquisadores alcançaram o mesmo código por relay com instrumentação, sem demonstrar a cadeia completa de exploração nesse caminho.[1] Portanto, restringir a porta direta é uma mitigação, não prova de que todo acesso por relay esteja seguro.

O exploit foi preparado para a compilação 8.0.2; a suspeita sobre versões anteriores não equivale a confirmação de exploração delas.[1] Preserve essa diferença no diagnóstico. Um crash, uma vulnerabilidade demonstrada e um comprometimento real são conclusões distintas.

Fonte

[1] Fonte: The Hacker News