Hacker News

Code-execution flaw in UEFI firmware threatens most servers on planet Earth

UEFI 펌웨어 코드 실행 취약점, 서버 부팅 과정 위협

UEFI 펌웨어 제작에 널리 쓰이는 TianoCore EDK II의 ICMP 구성 요소에서 CVE-2026-97631 메모리 손상 취약점이 발견됐습니다. 운영체제와 Secure Boot가 실행되기 전에 공격 코드가 동작할 수 있으며, 공개 패치로 공격법이 드러난 데다 여러 제조사 제품에 패치를 배포하는 데 시간이 걸립니다.

에디터 노트

이 취약점의 실질적인 범위는 모든 서버가 아니라 취약한 ICMP 구성 요소가 포함된 펌웨어와 공격자가 접근할 수 있는 부팅 네트워크에 달려 있습니다. 원문은 EDK II가 여러 UEFI 공급업체에서 널리 쓰인다고 설명하지만, 실제 제품 중 얼마나 많은 펌웨어가 해당 구성 요소를 포함하는지는 제시하지 않습니다. 따라서 제목의 광범위한 위협 표현과 구체적인 노출 규모는 구분해서 읽어야 합니다. 반면 공격이 운영체제와 Secure Boot보다 앞선 단계에서 이뤄진다는 점은 PXE를 다른 방식으로 조작하면 된다는 반론으로 해소되지 않습니다. 댓글에서는 measured boot와 BitLocker 우회 가능성이 제기됐지만, 이는 댓글 작성자의 설명이며 원문이 확인한 실제 악용 사례는 아닙니다. AMI의 수정 코드가 조율된 공개 일정보다 먼저 노출됐고, 공급업체별 펌웨어에 패치를 배포하기 어렵다는 원문의 설명이 현재 확인된 대응 과제입니다.

AI 요약

운영체제가 시작되기 전 실행되는 UEFI 펌웨어에서 코드 실행 취약점이 공개됐습니다. 취약점은 여러 하드웨어 제조사와 클라우드 사업자가 펌웨어를 만드는 데 쓰는 오픈소스 TianoCore EDK II에 있습니다. 공격자가 부팅 초기 단계에 코드를 실행하면 Secure Boot를 포함한 방어 체계보다 먼저 개입할 수 있습니다.

취약점과 영향 범위

CVE-2026-97631은 EDK II의 ICMP 구성 요소에서 발생하는 메모리 손상 취약점입니다. 기사에 따르면 CVSS 심각도는 10점 만점에 9.5점입니다. AMI, Insyde, Phoenix 등 UEFI 공급업체가 EDK II 참조 코드를 폭넓게 사용하며, Microsoft의 강화된 EDK II 포크인 Project Mu에도 취약한 코드가 포함됐습니다.

취약점을 이용해 전달한 최종 페이로드는 한 번만 실행되며 자체적으로 지속성을 유지하지 않습니다. 다만 공격자는 이를 발판으로 부팅 초기에 실행되는 다른 페이로드를 설치할 수 있습니다. 공격 시점이 운영체제보다 앞서므로 Secure Boot가 검사하는 신뢰 체계가 시작되기 전에 코드가 개입할 수 있다는 점이 기사에서 제기한 위험입니다.

공개 경위와 패치 문제

Anthropic의 Alex Matrosov와 Google의 Dan Holmes가 취약점을 발견했습니다. 양측은 1월에 맞춰 취약점을 공개하기로 조율했지만, 마더보드와 기타 하드웨어 제조사인 AMI가 지난달 취약점 설명과 수정 코드를 담은 pull request를 공개했습니다. 이 사실을 알게 된 뒤 TianoCore 프로젝트 구성원은 지난주 공개 권고문을 냈습니다.

수정 코드가 공개되면서 숙련된 공격자는 취약점 발동 조건을 파악해 실제 공격 코드를 만들기 쉬워졌다고 기사는 설명합니다. 반면 UEFI 코드는 수많은 제조사와 클라우드 사업자가 판매·운영하는 장비에 들어갑니다. 따라서 패치를 준비하고 수백만 대의 장비에 적용하는 과정은 복잡하고 시간이 걸립니다.

Hacker News 반응

  • @DamnInteresting — 이 취약점을 악용하려면 먼저 로컬 네트워크에 어느 정도 접근해야 한다는 중요한 제약이 있습니다. 따라서 내부자나 네트워크 안쪽까지 들어온 국가급 공격자 또는 랜섬웨어 운영자가 권한을 높이려는 상황으로 악용 범위가 제한될 가능성이 큽니다.
    • @bediger4000 — 이 취약점은 좀 이상하게 느껴집니다. PXE 부팅 자체가 취약한 절차인데, 공격자가 표적 ICMP 패킷을 보낼 만큼 네트워크에 들어왔다면 PXE 서버를 다른 방식으로 조작할 수도 있지 않나요?
    • @octoberfranklin — 하지만 그 방식으로는 부팅할 운영체제만 바꿀 수 있습니다. 이 취약점은 UEFI 단계까지 접근하게 해 거짓 증명을 만들 수 있습니다.
    • @amluto — 제대로 구성한 PXE 부팅 환경이라면 비밀 정보를 제공하기 전에 서버 상태를 증명하게 합니다. 이 취약점은 그 절차를 무너뜨립니다.
    • @mjg59 — 서버 환경 자체는 크게 걱정하지 않지만 펌웨어에서 코드를 실행하면 measured boot를 무력화할 수 있습니다. 그러면 기본 설정의 BitLocker도 우회할 수 있습니다.
  • @saidnooneever — EDK II는 빌드할 때 실제로 쓰는 구성 요소만 넣습니다. ICMP를 포함하는 펌웨어가 얼마나 되는지 궁금합니다. PXE를 쓰는 서버도 많지 않을 텐데 취약점이 대부분의 서버에 영향을 준다는 주장은 과장 아닌가요?
    • @Jhsto — 서버가 자체 서명한 이미지로만 부팅하고 PXE 서버가 그 이미지를 제공한다고 가정해 보세요. 메뉴를 바꾸거나 이미지를 바꿀 수는 없습니다. 하지만 Secure Boot 구성 요소가 실행되기 전에 부팅 체인을 공격하면 침입할 수 있습니다.
  • @FrasiertheLion — 최근 특정 기밀 VM 환경을 위해 약 100만 줄의 C 코드로 된 OVMF에서 300줄의 어셈블리로 된 최소 펌웨어로 옮기는 글을 썼습니다. 널리 쓰인다고 자동으로 안전한 것은 아닙니다. 코드가 작고 용도에 맞으면 LLM 분석, 퍼징, 형식 검증 같은 보안 작업을 적용하기도 수월합니다.
  • @mischanix — PHP 취약점 php2shell이 9.2점이었는데 이 취약점은 어떻게 9.5점인가요?
    • @gnabgib — PHP 취약점은 처음에는 10점으로 보고됐고 이론상 거의 모든 인터넷에서 원격 접근이 가능했습니다. 이 취약점은 물리적 하드웨어 접근이 필요해 사실상 영향받는 대상이 매우 적습니다. PHP 점수는 공개 과정에서 9.2점으로 조정됐으니 이 취약점도 나중에 8.7점이 될 수 있습니다.
    • @verandaguy — CVSS는 완벽한 체계가 아닙니다. 8점대 후반을 넘으면 점수와 관련한 왜곡된 유인이 생깁니다. LLM 기반 취약점 검색이 상업화되면서 이런 현상이 더 커졌습니다.
  • @userbinator — 과장된 공포 조성입니다. 인터넷에 연결된 네트워크에서 부팅하는 경우에만 해당하며 PXE 부팅은 매우 드뭅니다. 누가 공개 인터넷으로 PXE 부팅을 하나요?
    • @tptacek — 여러 대형 베어메탈 호스팅 업체가 사용합니다. 공개 인터넷으로 직접 부팅하지 않더라도 관리 네트워크를 공유하고 서버 한 대만 임대하면 접근할 수 있는 경우가 있습니다.
    • @kg — PXE 부팅은 매우 흔합니다. 저는 게임과 클라이언트 소프트웨어 분야에서 일하는데도 접해 왔습니다.

원문

Ars Technica / 번역·요약: Trawling

원문 보기 ↗토론 보기 ↗