Por que calcular somas de verificação de arquivos baixados?

Question

Muitas vezes vejo uma soma de verificação dada ao lado de um arquivo disponível para download. O propósito dessa prática me ilude. Obviamente, é para detectar arquivos corrompidos, mas o que poderia ser a causa dessa corrupção e é provável?

Certamente, o arquivo não será danificado por erros de transmissão, pois eles são detectados pelo protocolo de rede. E certamente qualquer invasor que pudesse alterar o arquivo para fins mal-intencionados também poderia alterar a soma de verificação fornecida. Estamos verificando se há erros no disco rígido? São mais propensos a acontecer quando se escreve, então, ao ler? Estou perdendo algo importante?

    

Answer 1

Para detectar a corrupção não está totalmente correto. Para verificar a integridade do software, seria um uso mais correto. Normalmente, um software não é distribuído a partir de um único servidor. O mesmo software pode ser distribuído a partir de muitos servidores. Portanto, quando você faz o download de um software específico, o servidor mais próximo de seu destino é escolhido como a origem do download para aumentar a velocidade de download. No entanto, esses servidores "não oficiais" (terceiros) não podem ser sempre confiáveis. Eles podem / podem incluir trojans / vírus / adware / backdoors no programa que não é bom .

Portanto, para garantir que o software baixado seja exatamente igual ao do software 'oficial' lançado pela organização em questão, a soma de verificação é usada. Os algoritmos usados para gerar somas de verificação são tais que até mesmo uma pequena alteração no programa resulta em uma soma de verificação totalmente diferente.

Exemplo retirado de Unix prático e segurança na Internet

MD5 (há $ 1500 na caixa azul.) = 05f8cfc03f4e58cbee731aa4a14b3f03

MD5 (há US $ 1100 na caixa azul.) = d6dee11aae89661a45eb9d21e30d34cb

As mensagens, que diferem apenas por um único caractere (e, dentro desse caractere, por apenas um único bit binário), possuem resumos de mensagens completamente diferentes.

Se o arquivo baixado tiver a mesma soma de verificação que a soma de verificação fornecida no site 'oficial', o software pode ser considerado não modificado.

Nota lateral: Em teoria, dois arquivos diferentes PODEM ter o mesmo valor de hash. Para que o algoritmo Hash / checksum seja considerado seguro, deve ser computacionalmente muito caro encontrar outro arquivo que produza a mesma soma de verificação.

    

Answer 2

And surely any attacker who could alter the file for malicious purposes could likewise alter the given checksum.

Nem sempre.

Você pode ter um link de conteúdo junto com uma soma de verificação em HTTPS. O link pode ser um link não criptografado - HTTP ou FTP simples ou qualquer outra coisa.

No lado negativo, a conexão não criptografada pode ser facilmente centralizada, no lado positivo, pode ser mais rápida ou mais conveniente para o webmaster (menos recursos de computação necessários e oportunidades para a rede armazenar essas coisas em cache).

Se a soma de verificação for veiculada em uma conexão confiável ininterrupta e a carga útil corresponder à soma de verificação, você obterá o melhor dos dois mundos (desde que a soma de verificação seja criptograficamente segura).

Dito isso, você me lembrou de que há distribuidores que afirmam estar "seguros" e, no entanto, o site deles está apenas no HTTP, assim como os links para as imagens deles.

Exemplos:

• link
• link

É engraçado porque você não pode ficar mais inseguro com isso. Mesmo que não sejam maliciosos, qualquer ISP pode facilmente substituir tanto o site quanto a imagem por falsificações, e fazer com que alguém instale um sistema operacional manipulado, fazendo com que pareça que está obtendo uma distribuição Linux "segura". pwnage.

    

Answer 3

Por que a verificação de erros do TCP / IP não captura tudo: Do link

Existem erros diferentes que podem ocorrer (que o TCP detectará) [apontado por Jacob Krall] :

• Ordem incorreta dos pacotes
• Perda de pacotes
• Dados corrompidos no pacote
• Pacotes fantasmas (o destinatário obtém pacotes que nunca foram enviados)

Edite com algumas informações adicionais:

Página 9 deste estudo: link sugere que há erros que podem passar despercebidos pelo TCP. Meu entendimento é que isso acontece quando um datagrama errôneo (chamado de "gêmeo ruim" no estudo) tem a mesma soma de verificação que o datagrama pretendido (chamado de "bom gêmeo" no estudo).

    

Answer 4

Erros de transmissão podem acontecer. Os protocolos de camada de link geralmente contêm somas de verificação ou códigos de correção de erros para evitá-los, mas não são perfeitos: há uma pequena chance de que um erro não seja corrigido. Os pacotes TCP também contêm uma soma de verificação, que reduz a probabilidade de erros em 2 ^ 16. Isso faz com que uma probabilidade muito pequena, mas diferente de zero, de um erro de transmissão. É o tipo de coisa que a maioria das pessoas nunca conhecerá, sem saber, em sua vida, mas não é na faixa de probabilidade de nunca chegar a bilhões de anos de checksums criptográficos.

É improvável que um erro de hardware no cliente, como corrupção de disco, seja detectado pela verificação logo após o download, porque a soma de verificação será calculada a partir da cópia em cache. Verificar se a mídia de inicialização está corrompida, caso não tenha conseguido inicializar, é útil, por outro lado, você está realmente testando a mídia e tem uma pressuposição de que o hardware pode estar com problemas.

O motivo real para calcular somas de verificação é, na verdade, detectar erros no nível do software. Isso acontece. Possíveis erros incluem:

• Um arquivo foi parcialmente baixado. Servidores Web e navegadores tendem a ser ruins para detectar conexões interrompidas e limpar arquivos parciais. O erro pode ter ocorrido durante o download ou pode ter ocorrido durante o upload, acrescenta.
• Houve alguma corrupção ao longo do caminho. Por exemplo, algum nó intermediário na distribuição do arquivo decidiu aplicar uma conversão de codificação de texto a um arquivo binário. Ou algum servidor mal configurado exibiu uma mensagem de erro em vez do conteúdo.
• Uma variante: o arquivo errado foi enviado.
• Raro, mas pode ser útil para proteção contra: um adversário alterou o arquivo, mas não conseguiu alterar a soma de verificação de referência. As infraestruturas de segurança tendem a dificultar que um invasor propague uma soma de verificação inválida do que um arquivo inválido. Por exemplo, arquivos grandes geralmente são distribuídos por meio de espelhos, enquanto as somas de verificação são atendidas por um site central com menos oportunidades de adulteração (acesso do servidor somente aos líderes do projeto, distribuição via HTTPS).

Na prática, verificar o tamanho do arquivo baixado captura os erros mais comuns, que são arquivos truncados ou convertidos de forma inválida. Os checksums têm a vantagem de detectarem estritamente mais problemas.

    

Answer 5

Em teoria, a rede entregaria todos os segmentos adequadamente e eles seriam montados corretamente no disco e nada iria dar errado.

Na realidade, os computadores são máquinas e software, ambos projetados e construídos por humanos falíveis. No caso de um download de alguma forma não cair certo por uma razão ou outra, como o download sendo através de algum dispositivo intermediário, seja ele inócuo ou nefasto que manipula os dados, é bom ter uma maneira de verificar se o arquivo quase certamente foi baixado como uma réplica exata do arquivo no lado do provedor.

Uma soma de verificação de alta qualidade é um método confiável para validar a integridade dos dados.

    

Answer 6

Nenhuma soma de verificação pode ser 100% confiável porque muitos arquivos são mapeados para a mesma soma de verificação.

Quando adicionamos outra soma de verificação ao trem, multiplicamos a probabilidade de detectar um erro.

Há muito tráfego na internet que os erros são bastante comuns.

    

Answer 7

A soma de verificação também ajudará a impedir o download corrompido devido à seguinte situação:

O servidor tem um erro interno ao servir o download, portanto, o download é encerrado.

Quando isso acontece, há alguns resultados possíveis:

• Bom servidor - a implementação do servidor de Codificação de transferência em partes não é buggy:
  • Bom cliente (como cURL, wget) poderá informá-lo que este é um download inválido, já que o fragmento final nunca foi enviado pelo servidor.
  • O mau cliente achará que o download foi concluído, pois não há mais dados sendo recebidos do servidor.
• Servidor incorreto - a implementação do servidor de codificação de transferência em partes é com bugs que envia a parte final para este download ruim:
  • Qualquer cliente achará que este download foi concluído com sucesso.

Eu já vi esses comportamentos entre ferramentas populares de clientes e estruturas de servidor, portanto, quando você não usa a soma de verificação, no caso de "servidor bom + cliente inválido" ou "servidor inválido + qualquer cliente", o download corrompido será despercebido.