Como autenticar uma imagem de disco de inicialização?

2

O processo de criação de um disco de inicialização no Ubuntu parece muito vulgar para mim. É assustador de várias maneiras. Por favor, (1) refute minhas afirmações com evidências contrárias ou (2) me diga como evitar essas armadilhas (esperançosamente sem desistir do Ubuntu como um sistema operacional quasisecure).

Primeiro de tudo, eis o que tentei fazer:

  1. Escreva um ISO do Ubuntu (autenticado por hash) através do Pen Drive Linux no Windows, para um pendrive USB, resultando em uma imagem inicializável.

  2. Instale a imagem de inicialização resultante no Computador A.

  3. Escreva o mesmo ISO em outro pendrive USB em outra máquina usando o Criador de disco de inicialização em um contexto Ubuntu diferente existente.

  4. Instale a imagem de inicialização resultante no Computador B.

  5. Use o Criador de disco de inicialização no computador A para criar um novo pendrive USB inicializável usando o ISO original acima, resultando na imagem A.

  6. Use o Criador de disco de inicialização no computador B para criar um novo pendrive USB inicializável usando o mesmo ISO, resultando na imagem B.

  7. Compare a imagem A e a imagem B. Em outras palavras, se eu começar com 2 maneiras diferentes de criar uma imagem de inicialização, as imagens de inicialização de seus filhos serão combinadas, se eu usar somente o Criador de disco de inicialização e não Pen Drive Linux na segunda rodada?

Aqui está o que aprendi, sem nenhuma ordem específica:

  1. O Criador de disco de inicialização tem um botão "Apagar disco", mas parece não funcionar porque parece preservar o tipo de sistema de arquivos. É realmente apagar o setor de inicialização (para não mencionar a tabela de partição), ou apenas deixando o mais recente vírus de boot lá, pronto para infectar o disco de inicialização recém-criado quando é usado para instalação? Sim, podemos usar o Utilitário de Disco para formatar mídia, mas seria bom se o Criador de disco de inicialização me dissesse que na verdade não estava inicializando nada de maneira adequada para inicialização segura. (Inicialização EFI pode mitigar parcialmente essa ameaça, mas provavelmente não a eliminaria.)

  2. Temos várias páginas no ubuntu.com que fornecem vários hashes para o ISO. Mas isso é irrelevante, porque no final das contas, todos queremos uma imagem de inicialização autenticada, não um arquivo compactado autenticado que eventualmente evolua para a imagem de inicialização mencionada anteriormente (depois de passar por uma máquina infectada etc. etc.).

  3. Temos md5sum.txt na imagem de inicialização. O MD5 foi suspenso por anos como um hash seguro. Sem mencionar que um vírus pode facilmente modificar este arquivo, então ele não pode substituir a necessidade de hashes de arquivos que podem ser baixados do link , não ao contrário de http (não s!): //releases.ubuntu.com/14.04/SHA256SUMS. Sim, claro, é ótimo para proteger contra erros acidentais, mas isso não afeta a segurança.

  4. O ldlinux.sys nem sequer é mencionado em md5sum.txt. É o único arquivo que difere entre a Imagem A e a Imagem B (novamente, embora tudo tenha vindo do mesmo ISO). Eu nem tenho uma soma de verificação para esse arquivo, muito menos um hash seguro. Pelo que sei, o Computador A e o Computador B estão infectados, mas com diferentes vírus que infectam esse arquivo de maneira diferente.

Aqui está o que eu quero saber como fazer:

  1. Uma maneira de autenticar a imagem infantil (on-line, não por meio de meios locais que possam ter sido infectados).

  2. Algum tipo de padrão que garante que o Criador de disco de inicialização eo Pen Drive Linux e o Random Boot Maker possam aderir, para que qualquer pessoa possa inspecionar facilmente o disco de inicialização resultante e dizer "este foi assinado pelo Ubuntu" ou menos "esses hashes parecem os mesmos que eu vejo no link ".

  3. Se nada mais, então o SHA256 e tamanho correto de ldlinux.sys para várias versões do Unbuntu.

  4. Sim, eu posso compilar tudo sozinho, mas não há motivos para acreditar que os vírus não infectariam o código-fonte, bem como o código binário. O mesmo problema de autenticação.

por Veiokej 16.05.2014 / 00:52

1 resposta

0

ldlinux.sys é para inicializar o Linux a partir de disquetes formatados em MSDOS. Imagens modernas do Ubuntu (como 14.04) não usam ldlinux.sys . Em vez disso, eles usam isolinux.bin , que faz parte da imagem de inicialização do El Torito do ubuntu.iso . Para jogar o cabeçalho do El Torito, faça o seguinte:

$  xorriso -indev ubuntu-14.04-desktop-amd64.iso -toc
xorriso 1.3.2 : RockRidge filesystem manipulator, libburnia project.

xorriso : NOTE : Loading ISO image tree from LBA 0
xorriso : UPDATE : 507 nodes read in 1 seconds
xorriso : NOTE : Detected El-Torito boot information which currently is set to be discarded
Drive current: -indev 'ubuntu-14.04-desktop-amd64.iso'
Media current: stdio file, overwriteable
Media status : is written , is appendable
Boot record  : El Torito , ISOLINUX isohybrid MBR pointing to boot image
Media summary: 1 session, 493568 data blocks,  964m data, 11.2g free
Volume id    : 'Ubuntu 14.04 LTS amd64'
Drive current: -indev 'ubuntu-14.04-desktop-amd64.iso'
Drive type   : vendor 'YOYODYNE' product 'WARP DRIVE' revision 'FX01'
Media current: stdio file, overwriteable
Media status : is written , is appendable
Media blocks : 493568 readable , 5895012 writable , 6388580 overall
Boot record  : El Torito , ISOLINUX isohybrid MBR pointing to boot image
Boot catalog : '/isolinux/boot.cat'
Boot image   : '/isolinux/isolinux.bin' , boot_info_table=on
Boot image   : '/boot/grub/efi.img' , platform_id=0xEF 
TOC layout   : Idx ,  sbsector ,       Size , Volume Id
ISO session  :   1 ,         0 ,    493568s , Ubuntu 14.04 LTS amd64
Media summary: 1 session, 493568 data blocks,  964m data, 11.2g free
Media nwa    : 493568s

Se você modificar qualquer uma dessas estruturas de inicialização, a soma de verificação (SHA256) do ubuntu.iso será diferente. Você pode obter o SHA256SUMS , SHA256SUMS.gpg , e o ubuntu.iso em releases.ubuntu.com . Você pode verificar uma imagem flash USB em uma unidade USB usando dd para gravar a imagem e depois lê-la de volta e compará-la ao original:

# checksum downloaded image (check this matches the published hash)
$ sha256sum ubuntu-14.04-desktop-amd64.iso
cab6b0458601520242eb0337ccc9797bf20ad08bf5b23926f354198928191da5  ubuntu-14.04-desktop-amd64.iso

# write image to USB flash
$ dd if=ubuntu-14.04-desktop-amd64.iso of=/dev/sdb

# read image from USB flash and checksum it
$ /bin/ls -l ubuntu-14.04-desktop-amd64.iso
-rw-r--r-- 1 user user 1010827264 Apr 17 10:51 ubuntu-14.04-desktop-amd64.iso
$ dd if=/dev/sdb bs=512 count=1974272 | sha256sum
1974272+0 records in
1974272+0 records out
cab6b0458601520242eb0337ccc9797bf20ad08bf5b23926f354198928191da5  -
1010827264 bytes (1.0 GB) copied, 34.1066 s, 29.6 MB/s

dd faz uma cópia binária exata, para que você possa comparar facilmente a imagem original com a imagem na unidade. Você precisará especificar um comprimento exato para ler de volta a partir da unidade USB, caso contrário, a soma de verificação será diferente.

Se você usar uma ferramenta diferente (não dd ) para gravar na unidade USB, ela poderá gravar dados binários diferentes, e você precisará gerar sua própria soma de verificação escrevendo usando sua ferramenta, e, em seguida, lendo a unidade com dd . Se você não confia em um único PC, mas confia em vários, então terá que recriar sua imagem em vários PCs e garantir que a imagem gere a mesma soma de verificação em todos.

Se você assumir que o computador que você usa para baixar a imagem e gravar o USB foi comprometido, você nunca poderá confiar em nada que ele faça. Ele poderia informar que a soma de verificação estava boa e que a imagem não havia sido adulterada - mas você nunca poderia confiar nela, porque ela já havia sido comprometida. Os pesquisadores conseguiram desenvolver sistemas que podem infectar o firmware EFI e, assim, sobreviver a uma limpeza completa do disco rígido e, ao mesmo tempo, informar que o Secure Boot está habilitado e funcionando bem, embora o sistema tenha sido totalmente subvertido. Uma vez que o sistema tenha sido comprometido, você nunca pode garantir totalmente que ele foi limpo. Daí porque a NSA tem um programa em vigor para redirecionar, interceptar e comprometer os sistemas alvo ainda nas mãos de um mensageiro, antes de ser entregue ao cliente.

    
por bain 16.05.2014 / 01:51