전 세계 서버 벤더와 데이터센터가 또 하나의 부팅 펌웨어 취약점에 대응해야 할 처지에 놓였다. 심각도 10점 만점에 9.5점으로 평가된 이 결함은 하드웨어 제조사와 클라우드 사업자가 UEFI 펌웨어를 만들 때 널리 쓰는 오픈소스 코드베이스 TianoCore EDK II에 존재한다. AMI, Insyde, Phoenix 같은 사실상 모든 UEFI 공급사(과거 명칭으로는 독립 BIOS 벤더)가 이 참조 코드를 광범위하게 사용하며, 마이크로소프트가 보안을 강화해 만든 EDK2 포크인 Project Mu에도 문제의 구성 요소가 포함돼 있었다.
CVE-2026-97631로 추적되는 이 취약점은 ICMP 처리 구성 요소의 메모리 손상 결함이다. 공격자는 이를 악용해 운영체제와 펌웨어가 보안 부팅(Secure Boot) 같은 방어 수단을 세우기 전, 즉 신뢰 사슬이 확립되기도 전에 악성 코드를 실행할 수 있다. 이 공격으로 전달되는 최종 페이로드 자체는 지속성이 없어 한 번만 실행되지만, 공격자가 부팅 초기마다 반복 실행되는 다른 페이로드를 심을 수 있는 넓은 발판이 된다는 점이 문제다.
16년 묵은 PXE 드라이버 버그
결함의 뿌리는 네트워크 부팅을 담당하는 PXE Base Code 드라이버(NetworkPkg/UefiPxeBcDxe)에 16년간 남아 있던 버퍼 오버플로다. 네트워크로 코드를 내려받아 부팅하는 PXE 과정에서 이 드라이버는 ICMP 오류 메시지를 수신하기 위해 리스너를 열어 두고, 받은 메시지를 504바이트 고정 필드(Mode.IcmpError)에 복사한다. IPv4와 IPv6 처리 핸들러 모두에서 복사 루프의 경계 처리가 잘못돼 있어, 504바이트를 넘는 메시지가 와도 계속 복사를 진행하고 목적지 포인터를 조각별 길이가 아니라 누적 길이만큼 전진시킨다. 그 결과 과도하게 긴 메시지는 공격자가 통제하는 바이트를 필드 바깥 인접 영역에 덮어쓰게 된다. 수신 경로 어디에서도 메시지 길이를 먼저 제한하지 않는다.
악성 오류 메시지는 PXE 부팅이 진행되는 동안 대상 기기의 IP 주소로 단순 유니캐스트를 보내는 것만으로 전달할 수 있다. 공격자는 부팅을 멈추게 해 서비스 거부를 유발할 수 있고, 대상 펌웨어 빌드를 알고 있다면 CPU의 가장 높은 권한인 링 0에서 악성 코드를 실행시킬 수 있다. 이 공격은 하드웨어가 안전하다는 것을 원격 서버에 암호학적으로 증명하는 어테스테이션 과정을 우회하기 때문에, 제한된 권한을 상승시키려는 공격자에게 특히 매력적인 통로가 된다.
Dragos의 최고연구책임자이자 Metasploit 제작자인 HD 무어는 이 결함이 신뢰 사슬과 생태계 전반에 미치는 방식이 흥미롭다고 평했다. 그는 공격자가 부팅 과정이 아직 TPM 같은 민감한 구성 요소에 접근할 수 있는 시점에 프로그램 흐름을 가로챌 수 있으며, 단기간 네트워크 접근만으로도 디스크 암호화를 깨는 데 쓸 수 있다고 지적했다. 기기 도난 상황이라면 더 쉬워진다는 설명이다.
공개 과정이 어그러진 대가
이 취약점은 Anthropic의 알렉스 마트로소프와 구글의 댄 홈스가 발견했고, 원래 1월로 예정된 협력 공개 때까지 비공개로 두기로 돼 있었다. 그러나 AMI가 지난달 결함 내용과 코드 수정을 담은 풀 리퀘스트를 공개하면서 일정이 어그러졌고, 이 사실을 인지한 발견자들과 TianoCore 프로젝트가 결국 지난주 공개 권고문을 냈다. 패치 코드가 공개돼 있는 만큼 숙련된 공격자가 작동하는 익스플로잇을 만드는 일은 어렵지 않을 것으로 보인다. 과거 EDK2의 PXE 결함에서 비롯된 PixieFail과 유사한 성격인데, 당시 발견 이후 진행된 여러 퍼징 프로젝트가 이번 결함은 잡아내지 못한 것으로 드러났다.
다만 악용에는 분명한 한계가 있다. 로컬 네트워크에 대한 일정 수준의 통제가 전제되므로 내부자나, 네트워크 내부에서 낮은 수준의 접근을 이미 확보한 국가 배후 조직·랜섬웨어 운영자 정도로 공격자가 제한될 가능성이 크다. 아직 이 취약점이 네트워크 최초 침투 경로가 된다는 증거는 없다. 펌웨어 보안업체 Eclypsium의 제시 마이클은 공격자가 대상 시스템 내부의 특정 주소를 추측해야 하므로 하나의 익스플로잇을 아무 기기에나 던져 원격 코드 실행을 얻는 식이 아니라, 모델·버전·설정별로 조정해야 한다고 설명했다. 그는 BootHole, Black Lotus, Baton Drop 같은 과거 사례와 달리 이번 결함은 기본적인 코드 수정으로 고칠 수 있어, 키 폐기나 pk/kek/db/dbx 관리 갱신 없이 BIOS/UEFI 업데이트 배포만으로 대응할 수 있다는 점을 긍정적으로 봤다.
실무자가 점검할 지점
이 결함은 디스크로만 부팅하는 가정·소규모 사무실 사용자에게는 영향이 없다. 로컬 네트워크나 인터넷 자원으로 부팅하는 조직의 기기에만 해당하며, 그마저도 EDK2 기반 펌웨어이면서 기본값으로 켜져 있는 PXE 기능을 사용할 때 문제가 된다. 인텔은 현재 보안 지원 중인 상용 제품은 영향을 받는 것으로 알려진 바가 없으며 자사 참조 코드에는 해당 EDK2 기능이 포함돼 있지 않다고 밝혔으나, OEM 보드 벤더나 시스템 제조사가 통합할 수 있다며 제조사에 문의할 것을 권했다. Arm 역시 자사 제품군에 직접 해당하지 않는다고 답했다. 다만 두 회사가 제공하는 펌웨어 모두 EDK2를 상당 부분 차용하고 있다는 점은 TianoCore 문서에도 남아 있어, 서버 사용자라면 영향 여부를 직접 확인하는 편이 안전하다.
당장 취할 수 있는 조치는 분명하다. 부팅에 쓰는 펌웨어 제조사에 영향 여부와 지침을 문의하고, 가능하다면 적어도 당분간 네트워크 부팅 기능을 끄는 것을 검토해야 한다. TPM과 보안 부팅 같은 기능은 이번 위협을 직접 막아 주지는 못하지만 항상 켜 두는 것이 바람직하며, 악용 시도 흔적을 찾기 위해 로그를 모니터링하는 것도 권장된다. 수천 개 제조사와 수백만 대 기기에 걸친 펌웨어 패치는 더디고 번거로운 작업인 만큼, 무어의 표현대로 지원이 끝난 시스템에 오래 남는 '영원한 버그'가 될 공산이 크다.