Modelo de segurança Yum OU Por que um proxy hostil pode negar atualizações sem um aviso?

Question

Um amigo meu só tinha o tipo mais estranho de problema em que seu Fedora 20 não atualizava (ou mesmo encontrava) o kernel atual 3.16.3 (e, por acaso, também não atualizava o vulnerável bash versão). Depois de limpar os caches, comparando os arquivos de configuração dele e meu e muitos arranhões de cabeça, finalmente me lembrei que ele estava usando uma VPN e pedi a ele para desligá-lo e tentar novamente. Funcionou sem falhas fora da VPN. Meu palpite é que a VPN impõe o proxy HTTP com um cache agressivo.

Isso me fez pensar sobre as afirmações de segurança que o yum pode dar ao usuário. Aparentemente, ele não pode detectar ataques de repetição no banco de dados do repositório, pois ele não recebeu nenhum aviso ou mensagem de erro sobre um estado obsoleto do repositório. Eu teria assumido que a visão geral do repositório era marcada com hora e assinada regularmente ou obtida via HTTPS (ou um hash do banco de dados seria buscado em HTTPS para reduzir a largura de banda do tráfego criptografado).

Eu sei que as assinaturas nos pacotes individuais são verificadas, para que eu possa pelo menos ter certeza de que nenhum pacote pode ser instalado no meu sistema que não tenha sido criado por uma parte confiável. Mas e quanto a atualizações parciais? Um proxy ou espelho mal-intencionado pode negar seletivamente as atualizações de pacote? Por exemplo. nunca atualizo o pacote bash vulnerável, mas repasso todas as outras atualizações, então não vou suspeitar de não receber nenhuma atualização?

Ou, pior ainda, um invasor pode até mesmo desmembrar seletivamente pacotes? Por exemplo. re-instalar o pacote openssl suscetível heartbleed?

    

Answer 1

Estou respondendo pela perspectiva de apt , mas acredito que seja o mesmo para yum .

Atualizações são obtidas via HTTP ou FTP, não HTTPS. A idéia é que a carga útil não precise ser criptografada, apenas não modificada, de modo que a segurança "suficiente" seja alcançada por uma assinatura PGP no índice. Mas o ataque de repetição é um problema!

Para poder ser redimensionável, as atualizações e os índices devem ser obtidos de um sistema "dumb mirror", para que os espelhos não possam realizar cálculos por conexão. Teoricamente, seria possível usar um segundo sistema apenas para buscar o índice e usar espelhos mudos apenas para os dados em massa.

Obviamente, é impossível garantir que você possa se conectar ao servidor. Se você confia no relógio do seu sistema local, você poderia verificar um timestamp que é incluído como parte da assinatura do PGP. Isso exigiria um bit pequeno de infraestrutura extra para garantir que a assinatura seja regenerada diariamente, mesmo que o conteúdo não mude, mas isso seria uma boa ideia para detectar espelhos obsoletos de qualquer maneira.

Para a última parte da questão - não, não é possível forçar um downgrade. Um aspecto fundamental do gerenciamento de pacotes é que, se o repositório remoto contiver uma versão mais antiga do que a que você possui atualmente, ela não fará nada.