Como meu rsync mínimo e seguro em memória em Go evita vulnerabilidades

 (michael.stapelberg.ch)
1 pontos por GN⁺ 1 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • gokrazy/rsync é uma implementação mínima de rsync escrita em Go, analisada com base em 12 vulnerabilidades do rsync divulgadas em janeiro de 2025 e maio de 2026
  • As verificações de limites e a inicialização com zero do Go transformam overflow de heap e vazamento de informação da stack em panic ou valores inofensivos, mas panic ainda pode resultar em negação de serviço
  • Problemas de travessia de caminho e da classe TOCTOU têm como defesa principal APIs de arquivos resistentes a travessia, como os.Root do Go 1.24, e o gokrazy/rsync foi totalmente migrado para isso
  • A estratégia de implementação mínima evita vulnerabilidades ligadas a recursos não implementados, como --inc-recursive, compressão, --safe-links, proxy e ACL de nome de host, reduzindo a superfície de ataque
  • A maior parte das vulnerabilidades veio de falta de validação e complexidade excessiva, e para casos de uso simples uma implementação simples pode ser mais adequada

Contexto e escopo

  • Em janeiro de 2025, vários pesquisadores de segurança divulgaram no upstream Samba rsync um total de 6 vulnerabilidades de segurança, e algumas delas permitem execução arbitrária de código e vazamento de arquivos
  • O ponto central da análise é se o gokrazy/rsync, uma implementação compatível e mínima escrita em Go, consegue de fato evitar essas classes de vulnerabilidade
  • O escopo da análise cobre 12 vulnerabilidades, somando o lote de janeiro de 2025 e o lote de maio de 2026
  • Se você executa o upstream rsync em produção, deve atualizar para 3.4.3 ou superior; o gokrazy/rsync deve ser atualizado para v0.3.3 ou superior
  • O gokrazy/rsync foi criado para fornecer os pacotes de software do projeto de pesquisa de distribuição Linux distri no router7, que é baseado na plataforma de appliance em Go gokrazy
  • No início havia apenas um servidor rsync, mas hoje ele suporta todas as direções e é usado em vários servidores gokrazy/rsync como funcionalidade básica de rsync que pode ser vinculada a programas Go

Vulnerabilidades de janeiro de 2025

  • CVE-2024-12084: estouro de buffer no heap, severidade 9,8

    • O rsync comparava o tamanho do checksum recebido pela rede com MAX_DIGEST_LEN, mas a estrutura de dados interna sempre usava o buffer de 16 bytes char sum2[SUM_LENGTH]
    • MAX_DIGEST_LEN pode ficar maior quando compilado com suporte a checksums SHA256 ou SHA512, permitindo que um atacante gravasse até 48 bytes além do limite do buffer sum2
    • O problema foi introduzido no commit ae16850 de setembro de 2022, que adicionou suporte a checksums SHA256/SHA512
    • A correção upstream substitui sum2 por sum2_array, alocado dinamicamente, e passa a alocar/verificar usando xfer_sum_len, o tamanho do checksum do algoritmo de transferência
    • Em Go, uma verificação de limites incorreta não leva a um estouro de buffer no heap; em vez disso, a verificação de limites em tempo de execução causa um panic
    • O gokrazy/rsync também não validava o cabeçalho de soma, mas não era uma confusão de tamanho; se ChecksumLength for alterado para 512, o runtime do Go gera panic: runtime error: slice bounds out of range [:512] with length 16
    • Como derrubar o servidor inteiro não é um modo de falha desejável, foi adicionada a verificação de limites que faltava para transformar o panic em error

  • CVE-2024-12085: vazamento de informações da stack para contornar ASLR, severidade 7,5

    • Pela mesma falta de validação da CVE-2024-12084, um atacante podia selecionar um algoritmo de checksum curto e depois alegar ter enviado um checksum mais longo
    • Segundo o Google Security report, a combinação do estouro de buffer no heap com o vazamento de informações permite que um cliente com apenas acesso anônimo de leitura execute código arbitrário na máquina do servidor rsync
    • hash_search() criava um digest de chunk em char sum2[MAX_DIGEST_LEN] na stack e o comparava com memcmp(), mas como o buffer local sum2 na stack não era inicializado, os bytes restantes podiam conter conteúdo da stack
    • Um cliente malicioso podia vazar 1 byte por download de arquivo, e os dados vazados podiam incluir ponteiros para objetos no heap, stack cookie, variáveis locais, ponteiros para variáveis globais e return pointer
    • “Some checksum buffer fixes” impediu que s->s2length, controlado pelo atacante, pudesse ser maior que o tamanho do checksum de transferência, e “prevent information leak off the stack” inicializou a memória de sum2 com 0
    • Em Go, todas as variáveis são inicializadas com o zero value, então essa vulnerabilidade não o afeta, e o gokrazy/rsync implementa a versão 27 do protocolo, não a versão 30 do protocolo, na qual foi introduzida a seleção de checksums além de MD4

  • CVE-2024-12087: path traversal usando link simbólico, severidade 7,5

    • Segundo o Google Security report, quando a sincronização de links simbólicos está ativada com -l ou -a (--archive), um servidor malicioso pode fazer o cliente gravar arquivos arbitrários fora do diretório de destino
    • O ataque funciona enviando várias listas de arquivos no modo --inc-recursive; na primeira lista, symlink aparece como diretório, e na lista seguinte o mesmo nome é trocado por um link simbólico apontando para fora do diretório de destino
    • O próprio Go não impede essa vulnerabilidade, porque a causa é um erro lógico: depois de mesclar várias listas de arquivos, não houve nova validação
    • A correção upstream adiciona a validação que faltava
    • O gokrazy/rsync não é afetado porque não implementa o modo de recursão incremental (--inc-recursive)
    • A recursão incremental permite processar os arquivos de forma “windowed”, sem varrer todo o conjunto antes do início da transferência, mas há um trade-off entre complexidade de implementação e uso de recursos

  • CVE-2024-12088: bypass de --safe-links, severidade 7,5

    • Segundo o Google Security report, --safe-links é um recurso que verifica se os links simbólicos recebidos do servidor apontam para dentro do diretório de destino
    • O bypass acontece porque ele não considera se existe outro link simbólico no meio do caminho de destino do link simbólico
    • Por exemplo, se houver {DESTINATION}/a -> . e {DESTINATION}/foo -> a/a/a/a/a/a/../../, foo na prática aponta para fora do diretório de destino, mas unsafe_symlink() considera isso seguro ao assumir que a/ é um diretório
    • A correção upstream torna unsafe_symlink() mais rigorosa, deixando de permitir ../ em posições que não sejam o início do caminho
    • O próprio Go não impede uma função de validação incorreta, e o gokrazy/rsync ainda não implementa o recurso --safe-links, então não é vulnerável

  • CVE-2024-12086: vazamento arbitrário de arquivos, severidade 6,8

    • O receiver do rsync, no modo cliente, não sanitizava os nomes de arquivos fornecidos pelo sender e não impedia a abertura de arquivos fora da árvore de destino
    • Um sender malicioso podia instruir o receiver a comparar checksums de arquivos arbitrários fora da árvore de destino e, observando a resposta do receiver a um checksum de 1 byte, podia vazar arquivos arbitrários
    • Segundo o Google Security report, quando um cliente se conecta a um servidor malicioso, o servidor pode vazar o conteúdo de arquivos arbitrários da máquina do cliente
    • A correção upstream valida os caminhos fornecidos pelo sender para impedir a abertura de arquivos fora da árvore de destino
    • Em Go, há APIs que podem evitar isso, e a defesa relacionada apontada é os.Root do Go
    • O gokrazy/rsync não é vulnerável porque implementa a versão 27 do protocolo, não a versão 29, na qual o recurso de fuzzy matching foi introduzido

  • CVE-2024-12747: condição de corrida com link simbólico, severidade 5,6

    • Segundo o Red Hat Security Advisory, trata-se de uma falha causada por uma condição de corrida durante o tratamento de links simbólicos no rsync
    • O comportamento padrão do rsync é pular links simbólicos quando os encontra, mas um atacante podia contornar esse comportamento padrão e fazer o rsync seguir o link simbólico ao trocar um arquivo normal por um link simbólico no momento certo

  • a correção upstream passou a usar a opção O_NOFOLLOW na chamada open() do sender do rsync

    • o gokrazy/rsync ficou vulnerável até o commit 1b1fbf6, que introduziu a mesma mitigação com O_NOFOLLOW do rsync upstream
    • Damien Neil considerou que a correção do CVE-2024-12747 no gokrazy era insuficiente, concluindo que O_NOFOLLOW só impede a travessia de links simbólicos no último componente do caminho
    • por exemplo, em os.Open("dir/passwd"), ainda é possível contornar isso substituindo o componente anterior do caminho, dir, por um link simbólico apontando para /etc
    • esse problema foi reportado ao contato de segurança do rsync em abril de 2025 e levou ao CVE-2026-29518, divulgado em 2026-05-20

Vulnerabilidades de maio de 2026

  • CVE-2026-29518: condição de corrida com link simbólico, severidade 7.0

    • Segundo a entrada NEWS do rsync 3.4.3, trata-se de uma condição de corrida TOCTOU com link simbólico que permite escalonamento local de privilégios no modo daemon sem chroot
    • Um daemon rsync configurado com use chroot = no fica exposto a uma corrida time-of-check/time-of-use em componentes de caminho pai
    • Um invasor local com acesso de escrita ao módulo pode trocar um componente de diretório pai por um link simbólico entre a verificação do receiver e o open(), causando divulgação de basis-file em leituras e sobrescrita de arquivos fora do módulo em gravações
    • O padrão use chroot = yes não é afetado
    • A correção upstream usa secure_relative_open(), semelhante à API os.Root do Go
    • O gokrazy/rsync ficou vulnerável até migrar sender e receiver para a API os.Root, resistente a traversals

  • CVE-2026-43618: vazamento remoto de memória por overflow de inteiro, severidade 8.1

    • O decodificador de tokens comprimidos do receptor rsync acumula um contador com sinal de 32 bits sem verificar overflow, permitindo que um remetente malicioso vaze conteúdo da memória do processo
    • Os dados vazados podem incluir variáveis de ambiente, senhas, ponteiros de heap e de bibliotecas, enfraquecendo o ASLR e facilitando exploits adicionais
    • O impacto se limita a conexões autenticadas com daemon e compressão ativada, habilitada por padrão no protocolo 30 ou superior quando ambos os pares anunciam compressão
    • A mitigação é desativar a compressão do daemon com refuse options = compress no rsyncd.conf
    • A correção upstream adiciona as verificações que faltavam
    • O gokrazy/rsync não é vulnerável porque não implementa compressão, e os motivos pelos quais o suporte a compressão parece simples, mas não é trivial, estão resumidos na issue #35 do gokrazy/rsync

  • CVE-2026-43620: negação de serviço após leitura fora dos limites, severidade 6.5

    • O problema existe porque a proteção parent_ndx<0 adicionada em 2025 a send_files() não foi aplicada ao bloco visualmente idêntico de recv_files()
    • Se um servidor rsync malicioso enviar a flag de compatibilidade CF_INC_RECURSE e uma flist malformada, o receptor pode ler e desreferenciar dir_flist->files[-1], levando a um SIGSEGV determinístico
    • O impacto atinge qualquer cliente rsync que faça um pull comum a partir de uma URL controlada pelo atacante, e a vítima não precisa de opções especiais por causa do inc_recurse, padrão no protocolo 30 ou superior
    • A mitigação é usar --no-inc-recursive no cliente, e a correção upstream adiciona a proteção parent_ndx<0 também em recv_files()
    • O gokrazy/rsync não é afetado porque não implementa o modo recursivo incremental --inc-recursive, assim como no CVE-2024-12087

  • CVE-2026-43619: condição de corrida adicional com link simbólico, severidade 6.3

    • A correção da condição de corrida com link simbólico nas chamadas open() do receptor (CVE-2026-29518) não foi aplicada a outras syscalls baseadas em caminho, como chmod, lchown, utimes, rename, unlink, mkdir, symlink, mknod, link, rmdir e lstat
    • Em um daemon rsync configurado com use chroot = no, um invasor local pode trocar um componente do diretório pai por um link simbólico entre a verificação do receptor e a syscall, redirecionando para fora do módulo exportado
    • O padrão use chroot = yes não é afetado
    • A correção upstream trata as syscalls baseadas em caminho afetadas por meio de um dirfd pai aberto sob restrições impostas pelo kernel, como openat2 no Linux 5.6+, O_RESOLVE_BENEATH no FreeBSD 13+ e macOS 15+, ou traversal componente por componente com O_NOFOLLOW nos demais ambientes
    • O gokrazy/rsync não é afetado porque usa amplamente a API os.Root do Go

  • CVE-2026-43617: bypass de ACL baseado em hostname, severidade 4.8

    • Em um daemon rsync com a configuração global daemon chroot = /X no rsyncd.conf, a resolução DNS reversa do cliente que se conecta era feita depois que o daemon executava chroot para /X
    • Se /X não tiver /etc/resolv.conf, /etc/nsswitch.conf, /etc/hosts e os módulos de serviço NSS necessários para a resolução da glibc, a consulta falha e o hostname da conexão é definido como "UNKNOWN"
    • Regras de negação baseadas em hostname, como hosts deny = *.evil.example, deixam de corresponder, permitindo que um atacante que controle registros PTR se conecte a partir de um hostname que o administrador pretendia bloquear
    • ACLs baseadas em IP não são afetadas, e a configuração use chroot por módulo não tem relação com essa vulnerabilidade
    • A correção upstream move a consulta DNS para um ponto mais cedo do protocolo
    • O gokrazy/rsync não é vulnerável porque não implementa listas de allow/deny baseadas em hostname e implementa apenas listas de allow/deny baseadas em IP

  • CVE-2026-45232: escrita fora dos limites da pilha, severidade 3.1

    • O suporte a proxy HTTP CONNECT no cliente rsync tem uma escrita off-by-one fora dos limites da pilha em establish_proxy_connection()
    • Se um proxy ou invasor man-in-the-middle retornar 1023 bytes ou mais na primeira linha de resposta sem '\n', o código subsequente pode escrever '\0' logo após o buffer de 1024 bytes, corrompendo um slot adjacente da pilha
    • O AddressSanitizer relata stack-buffer-overflow em socket.c:95 no frame de establish_proxy_connection
    • A correção upstream valida os dados fornecidos pelo atacante
    • O gokrazy/rsync não é vulnerável porque não implementa esse suporte a proxy

O que Go e o gokrazy/rsync realmente impediram

  • As verificações de limites do runtime do Go transformam problemas de segurança mais graves em panic; embora panic ainda represente risco de negação de serviço, é considerado um modo de falha melhor
  • O Go inicializa a memória com zero, tornando impossíveis vazamentos de informação como o CVE-2024-12085
  • A API os.Root do Go previne a maior parte das vulnerabilidades restantes
  • Das 12 vulnerabilidades, apenas a CVE-2026-43617 é classificada como um bug de lógica de aplicação que não pode ser evitado apenas com o uso de Go
  • A principal diferença entre o gokrazy/rsync e o rsync upstream oficial, além de ter sido escrito em Go, é que a implementação é minimalista
  • O gokrazy/rsync evita várias vulnerabilidades por não implementar diversos recursos problemáticos, como --inc-recursive, --safe-links, compressão, proxy e ACL por nome de host
  • Como toda implementação de rsync compatível com o wire protocol, o gokrazy/rsync tem como alvo a versão 27 do protocolo, e as versões posteriores introduzem uma complexidade considerável
  • Status do gokrazy/rsync por CVE no momento da publicação:
    • 2024-12084: havia implementação e ocorria panic
    • 2024-12085: recurso do protocolo 30, não implementado, portanto não vulnerável
    • 2024-12086: recurso do protocolo 29, não implementado, portanto não vulnerável
    • 2024-12087: não implementa inc-rec, portanto não vulnerável
    • 2024-12088: não implementa safe-links, portanto não vulnerável
    • 2024-12747: havia implementação e era vulnerável
    • 2026-29518: havia implementação e foi corrigido
    • 2026-43617: não implementa lista de negação de hosts, portanto não vulnerável
    • 2026-43618: não implementa compressão, portanto não vulnerável
    • 2026-43619: havia implementação e foi corrigido
    • 2026-43620: não implementa inc-rec, portanto não vulnerável
    • 2026-45232: não implementa proxy, portanto não vulnerável
  • Todas as vulnerabilidades conhecidas do gokrazy/rsync foram corrigidas, e o status acima representa a situação no momento em que cada CVE foi divulgado
  • Quando as vulnerabilidades foram divulgadas em janeiro de 2025, o gokrazy/rsync gerava panic no CVE-2024-12084 e era vulnerável à condição de corrida TOCTOU do CVE-2024-12747
  • No processo de correção do problema TOCTOU, o CVE-2026-29518 foi descoberto e corrigido no gokrazy/rsync antes da divulgação desse CVE
  • O CVE-2026-43619 foi descoberto mais tarde, mas já havia sido resolvido no gokrazy/rsync pela mesma correção: uso total de os.Root

Separação de papéis e nomenclatura das vulnerabilidades

  • Vários relatórios de vulnerabilidade usaram as expressões “server” e “client”, mas em uma transferência rsync tanto o cliente quanto o servidor podem assumir o papel de remetente (sender, upload de arquivos) ou destinatário (receiver, download de arquivos)
  • No modo daemon, o acesso ao sistema de arquivos pode ser restringido a caminhos de módulo pré-configurados, mas no command mode isso não acontece
  • As 4 configurações e as camadas de papel/protocolo podem ser vistas no diagrama rsync combinations
  • O título original da vulnerabilidade Arbitrary File Leak (CVE-2024-12086), “Server leaks arbitrary client files”, é propenso a causar confusão
  • A formulação mais precisa é que o destinatário do rsync vaza arquivos arbitrários para um remetente malicioso
  • Um cliente remetente malicioso pode, em ambientes como command mode via SSH, fazer com que um rsync remoto sem patch abra arquivos fora da árvore alvo, como o banco de dados de senhas do sistema /etc/shadow
  • No modo daemon, o servidor impede esse ataque ao ativar sanitização adicional de caminho (path sanitization)
  • A vulnerabilidade Symlink Path Traversal (CVE-2024-12087) também é descrita como “malicious server”, mas, com mais precisão, trata-se de um remetente malicioso, que pode ser tanto cliente quanto servidor

Comparação com o openrsync do OpenBSD

  • O projeto OpenBSD é conhecido pelo foco em segurança, e o openrsync não é afetado por Heap Buffer Overflow (CVE-2024-12084) nem Stack Info Leak (CVE-2024-12085), pois valida o comprimento do checksum e só oferece suporte ao MD4 em termos de tamanho/algoritmo de checksum
  • Assim como o gokrazy/rsync, o openrsync não é afetado por CVE-2024-12086, CVE-2024-12087 e CVE-2024-12088 porque não implementa os recursos relacionados
  • Mesmo que fosse vulnerável, ao rodar no OpenBSD, a defesa em profundidade por meio de OpenBSD unveil(2) e pledge(2), que restringem o acesso ao sistema de arquivos, poderia ter impedido uma exploração bem-sucedida
  • O openrsync não é afetado pelo CVE-2024-12747 porque passou a usar O_NOFOLLOW desde o momento em que implementou suporte a links simbólicos
  • Porém, como O_NOFOLLOW não é uma correção suficiente para esse problema, o openrsync é afetado pelo CVE-2026-29518
  • O pacote de maio de 2026 também é semelhante nesse sentido: a maior parte dos recursos relacionados não foi implementada
  • O openrsync evita o impacto da maioria das vulnerabilidades relatadas por implementar validações com rigor, limitar a superfície de ataque e aplicar defesa em profundidade

Defesa em profundidade e os.Root

  • Namespace de montagem no Linux

    • Poucas semanas após o início do projeto gokrazy/rsync, foi adicionado um recurso para restringir o acesso a objetos do sistema de arquivos usando redução de privilégios e namespaces de mount/pid no Linux
    • Essa abordagem funciona bem para mitigar ataques de travessia de caminho, mas exige privilégios, então é preciso executá-la como root ou dentro de um namespace de usuário do Linux, se isso estiver habilitado na distribuição/sistema
    • Namespaces de mount são adequados para configuração de servidor, mas muitas vezes não podem ser usados em transferências interativas e pontuais executadas na conta de um usuário comum

  • Hardening com systemd

    • O mesmo commit que introduziu suporte a namespaces de mount/pid no Linux também incluiu um arquivo de serviço do systemd que restringe o acesso ao sistema de arquivos ao diretório home, e o README recomenda restringir ainda mais o acesso ao sistema de arquivos conforme o caso de uso
    • Quando essas restrições do sistema de arquivos são configuradas corretamente, elas mitigam as vulnerabilidades File Leak (CVE-2024-12086) e Path Traversal (CVE-2024-12087)
    • Symlink Race Condition (CVE-2024-12747) depende de elevação de privilégios por meio do processo do rsync, mas graças ao recurso DynamicUser, o processo tem menos privilégios que outros usuários
    • Assim como os namespaces de mount, isso é bom para configuração de servidor, mas é trabalhoso de configurar para uso interativo e pontual

  • Linux Landlock

    • Por meio de Porting OpenBSD pledge() to Linux (2022), o autor foi lembrado de que o Linux também tem a API Landlock, um controle de acesso sem privilégios e por processo semelhante ao unveil(2) do OpenBSD
    • A ideia básica é que, depois que o programa sabe em quais diretórios vai trabalhar, ele faz uma chamada como unveil("/home/michael/backups", "rw"); para impedir qualquer acesso futuro a locais do sistema de arquivos fora desse caminho
    • Em março de 2025, foi implementado suporte ao Landlock para restringir o acesso ao sistema de arquivos
    • Depois que a configuração está ajustada, mesmo em execuções sem privilégios do gokrazy/rsync, é possível restringir a transferência rsync a acesso somente leitura na origem e leitura/gravação no diretório de destino
    • A desvantagem é que o Landlock opera no nível do processo
    • A política do Landlock também precisa incluir os arquivos necessários ao programa; por exemplo, gokrazy/rsync precisa poder ler /etc/passwd para consultar IDs de usuário, então, se um atacante mirar /etc/passwd, o Landlock não ajuda

  • os.Root do Go

    • Em fevereiro de 2025, o Go 1.24 introduziu a API os.Root, resistente a travessia de caminho, e o contexto relacionado está resumido por Damien Neil em The Go Blog: Traversal-resistant file APIs
    • Em comparação com o Landlock, os.Root oferece controle mais granular por operação no sistema de arquivos
    • O Go 1.25, lançado em agosto de 2025, adicionou mais métodos ao os.Root, tornando-o uma opção prática para a maior parte dos usos do sistema de arquivos
    • Todo o uso do sistema de arquivos em gokrazy/rsync foi migrado para os.Root, o que combina bem com o modelo em que o usuário configura os diretórios de entrada e saída, mas os nomes de arquivos recebidos pela rede não são confiáveis
    • Até chamadas de sistema que parecem não poder ser criadas diretamente pela API, como mknod(2), podem ser usadas com segurança
    • Damien Neil explica que é possível abrir o diretório pai do destino com os.Root.OpenFile, obter o descritor de arquivo desse diretório com File.Fd e então criar o arquivo com golang.org/x/sys/unix#Mknodat
    • Um exemplo de uso real está em internal/receiver/generatormknod_linux.go, line 15-29
    • No Linux existe mknodat(2), mas, no Linux 7.0, não existe um bindat correspondente a bind(2)
    • Lennart Poettering sugeriu que, sem bindat, é possível fazer bind em /proc/self/<fd>/foobar com um truque para ignorar a resolução de caminho
    • Se, depois do conhecido e seguro /proc/self/<fd>, for especificado não um caminho, mas um basename — ou seja, apenas o último componente do caminho — a resolução de caminho é ignorada; o código relacionado está nas line 49-56
    • Com essas duas dicas, gokrazy/rsync v0.3.1 ou superior passa a usar os.Root por completo, e todo acesso ao sistema de arquivos ganha segurança contra travessia de caminho

Principais lições

  • Todas as vulnerabilidades, exceto as falhas TOCTOU (CVE-2024-12747, CVE-2026-29518, CVE-2026-43619), surgiram da ausência de validação de entrada ou de validação incorreta de entrada
  • Em três casos não havia validação desde o início, e no CVE-2024-12088 o tema da resolução de caminhos no sistema de arquivos era complicado a ponto de a validação existente não cobrir todos os casos de borda
  • A correção estrutural mais valiosa é fornecer validação sempre ativa, como verificações de limites, e APIs seguras por padrão, como os.Root do Go
  • Algumas vulnerabilidades surgiram da evolução do protocolo rsync: novos recursos foram adicionados a um código que originalmente fazia validação suficiente, mas essa validação não foi atualizada corretamente
  • A negociação de algoritmo de checksum e a recursão incremental foram adicionadas na versão 30 do protocolo, e a validação existente não foi atualizada para corresponder à forma como os novos recursos eram tratados
  • gokrazy/rsync e openrsync não eram vulneráveis a 8 das 12 falhas de segurança simplesmente porque não implementavam os recursos vulneráveis
  • Esses recursos foram adicionados ao rsync porque, em algum momento, tiveram valor para alguém, e isso não significa que o desenvolvimento de software deva parar
  • A escolha ideal é usar uma implementação com complexidade adequada e proporcional à complexidade do caso de uso: escolher uma implementação simples para casos simples e recorrer a uma implementação completa apenas quando necessário

Leituras relacionadas

1 comentários

 
GN⁺ 1 시간 전
Comentários no Lobste.rs
  • Excelente artigo. É tão bom que todas as linguagens deveriam colocar uma API como os.Root na biblioteca padrão
    Depois de passar por algumas vulnerabilidades de travessia de diretórios no SecureDrop, usei uma versão bem simplificada, e agora, ao usar a API correta, uma classe inteira de vulnerabilidades desaparece
    • Sim. Parece que o protagonista deste post do blog não é Go, e sim os.Root