Secure Boot는 PC가 켜질 때 아무 코드나 실행되지 않도록 막는 부팅 보안 장치다. UEFI 펌웨어는 부팅 애플리케이션을 실행하기 전에 허용 목록인 db와 금지 목록인 dbx를 확인한다. 바이너리가 db에서 신뢰되지 않거나 dbx에 올라 있으면 부트 매니저는 실행하지 않고 보안 위반으로 처리한다.1
이번 이슈는 Secure Boot 자체가 무력하다는 이야기가 아니다. 핵심은 한때 정상적으로 서명되어 신뢰받았던 오래된 부팅 코드가 제때 폐기되지 않으면, 그 신뢰가 오히려 우회 경로가 될 수 있다는 점이다.
왜 Linux shim이 더 넓은 문제가 되나
Linux 배포판은 Secure Boot 환경에서 부팅하기 위해 shim이라는 작은 1단계 부트로더를 사용한다. Microsoft가 shim에 서명하면, shim은 다시 배포판의 GRUB 같은 2단계 부트로더를 검증하는 방식으로 신뢰 체인을 이어 간다.1
이 구조가 중요한 이유는 Microsoft Corporation UEFI CA 2011 인증서가 Linux shim뿐 아니라 복구 도구, 디스크 암호화 유틸리티 같은 서드파티 UEFI 부팅 소프트웨어 서명에도 사용되기 때문이다.1 또한 대부분의 OEM은 새 PC에서 Secure Boot가 바로 동작하도록 Microsoft UEFI 인증서들을 db에 등록한다.1
따라서 특정 Linux 배포판이 설치된 장비만의 문제가 아니다. 공격자는 취약한 UEFI 애플리케이션을 직접 가져와 부팅 과정에 투입할 수 있다.1 영향 범위는 해당 소프트웨어 사용자에 그치지 않고, Microsoft 서드파티 UEFI 인증서를 신뢰하는 UEFI 시스템 전반으로 넓어진다.1
오래된 신뢰 체인이 공격 표면이 된다
ESET은 Microsoft가 서명한 오래된 UEFI shim 11개를 확인했다. 이 중에는 최소 2013년의 shim도 포함되어 있었고, CERT가 정리한 목록에는 Red Hat, OpenSUSE, Oracle 등 Linux 배포판에서 사용된 shim이 포함됐다. Microsoft는 ESET이 CERT와 Microsoft에 해당 shim들을 알린 뒤 6월 월례 패치에서 11개 shim을 dbx 업데이트로 폐기했다.1
불편한 지점은 취약점이 shim 하나에서 끝나지 않는다는 것이다. 구형 shim 뒤에는 대개 GRUB 2 같은 2단계 부트로더가 있으며, 그 뒤쪽 신뢰 체인에도 오래된 취약점이 남아 있을 수 있다.1 결국 Secure Boot의 강도는 “현재 켜져 있는가”보다 “무엇을 계속 신뢰하고, 무엇을 더 이상 신뢰하지 않는가”에 달려 있다.
Windows 11 Secured-core PC는 Microsoft 서드파티 UEFI 서명 옵션이 기본적으로 비활성화되어 있어야 하므로 기본 상태에서는 영향이 제한될 수 있다.1 그러나 일반 PC, 서버, 오래 운영한 장비에서는 dbx 업데이트가 실제로 적용되어 있는지 확인할 필요가 있다.
지금 확인할 것
가장 중요한 조치는 최신 dbx 업데이트를 적용하는 것이다. ESET도 보호 방법으로 최신 Microsoft dbx 업데이트 설치를 권고한다.1
Windows 사용자는 Windows 보안 앱에서 Secure Boot 인증서 업데이트 상태를 확인할 수 있다. 일부 장치는 펌웨어 한계나 OEM 업데이트 필요 때문에 인증서 업데이트가 지연될 수 있으며, 이 경우 장기적으로 새 부팅 위협을 차단하는 능력이 줄어든다.2
이번 사건의 교훈은 단순하다. Secure Boot는 “켜져 있음”만으로 끝나는 기능이 아니다. 허용 목록과 폐기 목록이 계속 갱신되어야, 서명 기반 신뢰가 실제 보안 통제로 남는다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.