%EC%97%90%EC%84%9C%20%EB%B0%9C%EA%B2%AC%EB%90%98%EC%97%88%EC%8A%B5%EB%8B%88%EB%8B%A4.%20%EB%B6%80%ED%8C%85%20%EA%B0%80%EB%8A%A5%ED%95%9C%20%EC%9E%A5%EC%B9%98%20%EC%A4%91%20%EB%B3%B4%EC%95%88%20%EB%B6%80%ED%8C%85%20%ED%99%95%EC%9D%B8%EC%9D%84%20%ED%86%B5%EA%B3%BC%ED%95%9C%20%EC%9E%A5%EC%B9%98%EA%B0%80%20%EC%97%86%EC%8A%B5%EB%8B%88%EB%8B%A4..png)
방금 다음 웹사이트에서 Pop!_OS 22.04 LTS(NVIDIA)를 다운로드했습니다.공식 웹 사이트, 체크섬을 확인하고 펜 드라이브에 플래시한 후 부팅을 시도합니다.
웹사이트에서 권장하는 대로 보안 부팅을 비활성화하는 것을 잊어버렸기 때문에 예상한 대로 오류 메시지가 나타났습니다. 그러나 이메일의 실제 내용은 나를 놀라게 했습니다.
운영 체제 로더 서명이 SecureBoot 제외 데이터베이스("dbx")에서 발견되었습니다. 부팅 가능한 장치 중 보안 부팅 확인을 통과한 장치가 없습니다.
서명 데이터베이스에서 서명을 찾을 수 없을 것이라고 예상했지만,들어오지 못하게 하다데이터 베이스.
~에 따르면이 웹사이트:
dbx, "서명 데이터베이스 금지". 여기에 항목은 일반적으로 특정 UEFI 바이너리의 SHA256 해시입니다. 즉, "db" 목록의 인증서로 서명되었지만 나중에 잘못된 것으로 밝혀진 바이너리(예: 펌웨어를 손상시키는 보안 취약점이 있음)입니다. 따라서 이것은 "차단" 목록입니다.
System76에서 제공한 소프트웨어 서명이 한때 유효했지만 나중에 잘못된 것으로 밝혀진 이유는 무엇입니까?
이는 Pop!_OS의 잠재적인 취약점을 나타내는 신호입니까?
답변1
2020년 중반에 프로젝트CVE-2020-10713 또는 BootHole설립하다. acpi이는 GRUB2 및 보안 부팅을 사용하고 보안 부팅 호환 구성에 GRUB 모듈을 포함하는 거의 모든 배포에 영향을 미칩니다 . 이후 보안 연구원들은 다른 유사한 취약점을 찾기 위해 부팅 프로세스에 더 많은 관심을 기울였습니다.
이로 인해 2021년 3월 GRUB2에서 추가 취약점 세트가 발견, 수정 및 릴리스되었습니다.이 외에도 Debian은 이전 Secure Boot 서명 키를 취소하고 새 키를 생성하고 부트로더 서명 프로세스를 일부 변경해야 합니다. 우분투에도 비슷한 보안 부팅 인프라가 있으므로,그 사람들도 똑같은 일을 해야 해.
Debian/Ubuntu에서 Secure Boot 인프라를 복사하는 다른 배포판도 동일한 작업을 수행해야 합니다. 보안 연구원 프로젝트의 또 다른 부분은 shimx64.efi취약한 GRUB 및 버전의 해시 목록을 수집하고 Secure Boot 서명 키를 취소하는 것이기 때문입니다. 이 목록은 향후 보안 부팅 펌웨어를 위한 제외 데이터베이스에 추가되고 결국 보안 부팅 제외 데이터베이스 업데이트로 기존 시스템에 배포됩니다.
2022년 8월 9일에 Microsoft는 취약한 GRUB 버전에 대한 제외를 포함하는 Windows 보안 부팅 제외 데이터베이스에 대한 업데이트를 출시했습니다. 또한 fwupdLinux/시스템용 보안 부팅 dbx에 대한 업데이트 도 출시했습니다 fwupdmgr. 모든 주요 운영 체제가 포함되도록 하기 위해 Linux 배포판과 운영 체제 공급업체 간에 어느 정도 조정이 있다고 가정하는 것이 타당해 보입니다.
이제 Pop!_OS의 부팅 구성 요소가 최신 제외 목록과 일치한다면 이는 해당 구성 요소가 2021년 3월 이전 Debian에서 유래했다는 의미입니다. 즉, Debian 10.9 이하와 동등한 수준에 있다는 의미입니다. Pop!_OS가 일부 업데이트를 건너뛰는 것 같습니다.
물론 그들은 보안 부팅을 비활성화하는 것을 권장하지만 Pop!_OS는 해당 Ubuntu 버전을 기반으로 하기 때문에 Ubuntu의 보안 부팅 지원은 Pop!_OS 22.04 LTS도 기능적 보안 부팅 지원을 구현할 수 있어야 함을 시사합니다. 어쩌면 System76(Pop!_OS 개발자)이 Microsoft로부터 보안 부팅 인증서를 받는 것을 건너뛰기로 결정했을 수도 있습니다. 나에게 이는 Pop!_OS의 초점이 내용보다는 스타일에 더 중점을 둘 수 있음을 의미합니다.
기본적으로 2022년 8월 9일에 보안 부팅을 철회하는 목적은 취약한 구성 요소를 사용하는 동안 느끼는 잘못된 보안 감각을 제거하는 것입니다. 시스템은 애초에 보안 부팅이 없는 시스템보다 더 취약하지 않습니다. .
시스템이 물리적으로 안전하다면 공격자가 이러한 취약점을 악용하여 시스템에 침입할 수 있는 실질적인 방법이 없어야 합니다. 그러나 보안 부팅을 사용하여 Evil Maid 유형의 공격을 "의도한" 공격자 수준보다 더 어렵게 만드는 경우 Pop!_OS는 현재 해당 사용 사례에 대한 잘못된 선택일 수 있습니다.