{"id":182443,"date":"2026-07-02T22:53:28","date_gmt":"2026-07-02T20:53:29","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/problemy-s-ochistkoj-klyuchej-shifrovaniya-diska-iz-ozu-pri-perehode-linux-v-zhdushhij-rezhim"},"modified":"2026-07-02T22:53:28","modified_gmt":"2026-07-02T20:53:29","slug":"problemy-s-ochistkoj-klyuchej-shifrovaniya-diska-iz-ozu-pri-perehode-linux-v-zhdushhij-rezhim","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/news\/problemy-s-ochistkoj-klyuchej-shifrovaniya-diska-iz-ozu-pri-perehode-linux-v-zhdushhij-rezhim","title":{"rendered":"Problemas ao limpar chaves de criptografia de disco da RAM ao passar o Linux para o modo de espera","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Durante a portabilidade do utilit\u00e1rio cryptsetup-suspend para NixOS, foi identificada uma falha no subsistema de criptografia de disco LUKS (Linux Unified Key Setup), que impediu a limpeza das chaves de criptografia da mem\u00f3ria RAM quando o sistema entra em modo de espera, a partir do kernel Linux 6.9 (commit problem\u00e1tico) lan\u00e7ado em maio de 2024. <\/p>\n
A ferramenta cryptsetup-suspend \u00e9 usada no Debian para bloquear automaticamente as parti\u00e7\u00f5es LUKS antes de entrar no modo de suspens\u00e3o. Assume-se que, em caso de roubo de um laptop colocado em modo de suspens\u00e3o, o invasor n\u00e3o ter\u00e1 acesso aos dados, pois ao sair do modo de suspens\u00e3o ser\u00e1 necess\u00e1rio inserir uma senha para restaurar o acesso aos dados criptografados. Devido a um erro no n\u00facleo do Linux, ap\u00f3s o bloqueio da parti\u00e7\u00e3o LUKS com o comando «cryptsetup luksSuspend», as chaves n\u00e3o eram removidas da mem\u00f3ria RAM e permaneciam vis\u00edveis atrav\u00e9s de \/proc\/keys, permitindo que um atacante as extra\u00edsse, por exemplo, usando o m\u00e9todo «reinicializa\u00e7\u00e3o fria», e as usasse para acessar os dados. <\/p>\n
A falta de limpeza das chaves foi descoberta durante a depura\u00e7\u00e3o de uma condi\u00e7\u00e3o de corrida que causava problemas ao entrar em modo de espera. A falha surgiu ap\u00f3s uma refatora\u00e7\u00e3o no kernel 6.9, onde as chaves eram vinculadas ao thread chamador e deveriam ser removidas ao seu t\u00e9rmino, mas na pr\u00e1tica permaneciam na mem\u00f3ria. Um patch de uma linha foi proposto para ser inclu\u00eddo no kernel Linux, corrigindo a falha cometida. <\/p>\n
Este patch n\u00e3o foi aceito no n\u00facleo, pois foi identificada uma falha \u2014 o patch funciona apenas para unidades f\u00edsicas, mas n\u00e3o para dispositivos virtuais loop. Em vez de corrigir o problema do lado do n\u00facleo, os desenvolvedores da ferramenta cryptsetup propuseram uma solu\u00e7\u00e3o alternativa para limpar as chaves. Essa altera\u00e7\u00e3o j\u00e1 foi aceita e far\u00e1 parte da vers\u00e3o 2.8.7 do cryptsetup. <\/p>\n