.
Não entrar em pânico. Sim, houve vários CVEs afetando potencialmente centenas de milhares de usuários encontrados no rsync no início de dezembro – e tornados públicos na terça-feira – mas uma versão corrigida foi lançada no mesmo dia e foi ajustada para melhor compatibilidade no dia seguinte.
Não há ataques conhecidos que explorem as falhas em estado selvagem.
A meia dúzia de falhas de segurança no rsync foram anunciadas no Openwall em 14 de janeiro. Uma delas tem uma pontuação de gravidade CVSS de 9,8 em 10, e a descrição diz:
Como isso afeta todas as versões do rsync desde a versão 3.2.7 em outubro de 2022, esperamos que qualquer pessoa que execute um servidor rsync público o atualize rapidamente. Os outros são menos severos, na faixa de 5,6 a 7,5, mas são tão antigos quanto o próprio rsync, que remonta a 1996.
Boas notícias: essas vulnerabilidades foram identificadas em dezembro do ano passado, e o rsync 3.40, lançado um dia após o anúncio do Openwall, corrige todas elas. Essa versão introduziu algumas regressões, e no dia seguinte (15 de janeiro) vi uma versão menor para correção de bugs, versão 3.4.1. Como este é um problema de alta prioridade – o BleepingComputer afirma ter identificado 600.000 máquinas afetadas – os distribuidores Linux estão no caso.
Por exemplo, a Canonical lançou uma atualização para o Ubuntu 14.10 no dia do anúncio. Como seria de esperar, exceto pelo último lançamento “Oracular Oriole”, ele cobre apenas versões LTS. Se você ainda estiver executando o CentOS Linux, esperamos que esteja pagando alguém pelas correções.
Esse sentimento de sincronização
Rsync é uma ferramenta muito interessante. O que isso faz parece um pouco com mágica. Ele sincroniza duas cópias de um arquivo arbitrariamente grande em uma conexão relativamente lenta, sem enviar o conteúdo do arquivo pela linha. Quando se trata de distribuição de atualizações de software, este é um superpoder. E é FOSS. Como resultado desses dois fatores, é excepcionalmente amplamente utilizado por todos os tipos de sistemas operacionais. Portanto, as vulnerabilidades no rsync afetam muitos computadores.
Isso significa que os seis CVEs de 14 de janeiro são um grande negócio. Os cinco primeiros têm números consecutivos e resultam de problemas registrados no Bugzilla da Red Hat em 5 de dezembro. O grave é um estouro de buffer de heap no rsync devido ao tratamento inadequado do comprimento da soma de verificação, e os próximos dois também estão relacionados a somas de verificação – vazamento de informações via conteúdo de pilha não inicializado (mas é apenas um byte) e o vazamento bastante mais preocupante de arquivos arbitrários de clientes. Os próximos dois são uma vulnerabilidade de passagem de caminho e o desvio da opção de links seguros leva à passagem de caminho.
Tudo isso foi relatado pela mesma equipe de pesquisadores de segurança do Google – Simon Scannell, Pedro Gallegos e Jasiel Spelman. A última, condição de corrida que lida com links simbólicos, foi encontrada em 18 de dezembro pelo pen-tester russo Aleksei Gorban, um veterano da Kaspersky que agora trabalha para o TikTok. ®
Nota de inicialização
A Microsoft, que tende a gostar de fazer as coisas à sua maneira, tem seu próprio protocolo para realizar a mesma tarefa do rsync, chamado Remote Differential Compression (RDC).
Como seria de esperar, em 2006, a Microsoft afirmou que isso era melhor, mas como os espectadores mais cínicos podem antecipar, você também pode encontrar o RDC na lista de recursos obsoletos do Windows Server 2019.
.
