Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
본 기사는 UEFI와 같은 거대한 펌웨어의 복잡성과 보안 취약점을 지적하며, 공격 표면을 줄이는 것이 중요하다고 강조합니다. 기능을 최소화하고 작은 전용 코드베이스를 만드는 접근이 필요하며, seL4와 같은 경량 커널 구조가 구조적인 해결책으로 제시됩니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기특정 기밀 VM 환경에서 OVMF의 C 코드 약 100만 줄을 어셈블리 300줄짜리 전용 펌웨어로 대체한 과정을 최근 정리했음. 널리 쓰인다고 자동으로 안전해지는 것은 아님.
큰 코드베이스에 LLM을 적용하면 취약점을 찾을 수 있으므로, 세상의 모든 코드를 패치하는 접근은 확장성이 부족함. 대신 용도를 좁힌 작은 코드베이스를 만들고 LLM, 퍼징, 정형 기법 등 보안 수단을 집중 적용할 수 있음. 코드가 작으면 LLM 활용 비용도 낮아짐. https://tinfoil.sh/blog/2026-10-25-less-is-more
나도 비슷하게 생각해 왔음. 공격 표면을 줄이기 위해 의존성과 코드 크기를 최소화하려는 수요가 빠르게 커질 듯함.
널리 쓰인다는 것은 대개 다양한 용도를 지원한다는 뜻이고, 그만큼 코드와 복잡성이 늘어나기 쉬움. 이제 특정 용도에 맞춘 펌웨어를 활용하기가 훨씬 수월해졌고, 정형 검증까지 가능할 수 있음.
백지에서 다시 만드는 접근이 필요함. 여러 계층은 다시 만들 수 있고 그래야 하며, 기능을 줄이지 않더라도 상당한 코드를 덜어낼 수 있을 듯함.
비개발자에게 소프트웨어 비대화를 설명할 때는 몇 년마다 한 층씩 증축하고 중간중간 개조해 완성한 10층 건물에 비유함. 비효율이 쌓일 수밖에 없음. 리팩터링도 하지만, 실제 운영을 통해 필요한 것을 정확히 파악한 뒤 새로 만들면 훨씬 간결해질 수 있음.
필요한 핵심 기능만 남겨 C 100만 줄을 어셈블리 300줄로 줄였다는 접근이 마음에 듦. 다만 이번에는 저수준 코드라는 유리한 조건이 있었음.
최근 PHP 사태처럼 프레임워크·런타임·인터프리터 위에서 실행되는 애플리케이션이 걱정됨. 애플리케이션 코드를 아무리 강화해도 기반 코드가 안전하지 않으면 한계가 있고, 공격자가 방어자보다 유리하다는 점까지 겹침. 지금으로서는 일종의 사설망이나 VPN으로 보호하는 방법밖에 떠오르지 않는데, 어떻게 생각하는지 궁금함.
그래서 구조적인 해결책이 필요함. 예를 들어 seL4는 모놀리식 커널보다 작고, 알려진 버그가 없으며, 특권으로 실행해야 하는 유일한 구성요소임. AI도 찾아볼 수 있겠지만 아직 성과는 없음. seL4 아래에서 실행되는 모든 구성요소가 seL4의 보장을 누릴 수 있음.
UEFI가 만들어진 이유를 늘 의심해 왔음. 운영체제보다 먼저 코드를 실행하지만 BIOS 같은 하드웨어 추상화 계층을 제공하는 것도 아닌데, 대부분의 운영체제가 BIOS나 다른 소프트웨어 계층 없이 하드웨어를 직접 설정한다면 왜 필요한지 모르겠음.
비교적 작은 BIOS와 달리 UEFI는 거의 운영체제 규모이며 자체 애플리케이션까지 실행함. C 코드 100만 줄에 버그가 가득하고 이번 취약점은 그중 하나일 뿐임. LLM이 훨씬 더 많이 찾아낼 것임.
UEFI도 하드웨어 추상화를 제공하며, 오히려 훨씬 많은 기능을 제공함. .efi 프로그램은 펌웨어 서비스를 통해 파일을 읽고 텍스트를 출력할 수 있고, 거의 DOS의 80%쯤 들어 있는 셈임.
운영체제를 처음 불러오려면 NVMe 드라이버, 네트워크 부팅용 이더넷 드라이버, 부팅 대상을 고를 키보드 입력과 화면 출력 등이 필요함. 하나의 공유 MBR에서 운영체제나 부트로더를 불러오는 방식은 끔찍했으므로 파일시스템 드라이버도 필요함.
하드웨어 추상화 계층이 없다는 말이 무슨 뜻인지 모르겠음. UEFI는 저장장치·네트워크·입력장치·프레임버퍼에 접근하는 일관된 인터페이스를 제공함. 그렇지 않으면 부트로더가 어떻게 작동하겠는가?
대부분의 ARM/ARM64 싱글보드 컴퓨터가 얼마나 엉망인지 보면, GRUB 등을 실행할 표준 인터페이스의 장점을 이해할 수 있음. 물론 UEFI를 훨씬 작게 만들 수도 있음.
UEFI의 가치는 확실히 의문스럽기도 함. 최근 Linux에서는 BIOS를 업데이트할 방법이 없어 Windows PE를 사용했고, 기본 부팅 설정도 초기화됐음. 그런데 재미있게도 Windows PE로 Linux 부팅을 복구할 수 있었음.
예전에는 fdisk /mbr로 Windows 부팅을 복구하거나 USB·CD로 Linux를 부팅해 GRUB/LILO를 재구성해야 했음. 후자는 지나치게 복잡해져서 수작업으로 하고 싶지 않음.
UEFI가 잘하는 부분은 있지만, 기업용으로 설계되면서 복잡성이 지나치게 커졌다고 봄. 결국 모두가 같은 원본 코드베이스를 사용할 수밖에 없을 정도임.
취약점을 1월 공동 공개 때까지 비밀로 유지하기로 했다는 식의 순진한 낙관은 곧 사라지길 바람. 특히 AI로 찾았거나 AI의 도움을 받아 발견한 취약점이라면 더욱 그러함.
흥미로운 부분은 Secure Boot나 BitLocker를 우회할 가능성임. UEFI가 잠겨 있고 Secure Boot가 강력하게 설정되어 있어도 PXE 부팅이 잘못 활성화되어 있다면, 부팅 신뢰 사슬을 깨고 Secure Boot를 끄거나 TPM에서 키를 추출할 수도 있음.
핵심은 공격 대상 장치에서 PXE 부팅이 얼마나 자주 활성화되어 있느냐임. 주로 기업용 노트북이나 Chromebook, 일부 Microsoft Surface처럼 제조사가 잠가 둔 장치가 떠오름.
요즘은 서버도 잠가 두지 않는가? TPM에 키를 저장한 암호화 부팅 이미지를 사용하고 PXE 프로비저닝 시스템에서 부팅할 수도 있음. 이 취약점으로 부팅 이미지를 수정할 수 있을까?
서버가 부팅하는 동안 ICMP 패킷을 보내야 한다면 공격 표면이 극히 좁아 보임. 우리 기업용 서버는 계속 켜져 있어서 마지막으로 부팅한 게 언제인지도 모르겠음.
정확히는 PXE로 부팅하는 동안 ICMP 패킷을 보내야 함. 서버가 PXE로 부팅하고, 인터넷 연결과 같은 인터페이스를 사용하며, 비정상적이거나 예상 밖의 ICMP 패킷을 차단하는 방화벽이 없고, 물리 서버가 재부팅되는 순간까지 맞춰야 한다는 뜻임.
서버를 원격 침해할 공격 표면은 사실상 없어 보임. 반면 클라이언트 장치는 훨씬 공격하기 쉽고, Secure Boot 우회는 DRM 우회나 게임 부정행위뿐 아니라 장치에 몰래 물리적으로 접근하는 공격자와 정보기관에도 매력적일 것임.
패킷을 계속 보내다가 서버가 한 번만 부팅해도 충분함. 부팅 시점을 미리 알 필요는 없음.
공격 기법이 공개되기 전이라면 데이터센터 전체에 악성 ICMP 패킷을 계속 보내고, 재부팅이 필요한 다음 커널 패치를 기다리는 방식이 꽤 현실적이었을 것임. 그 패킷이 단순한 잡음이 아니라는 사실을 모르면, 당장 장애를 일으키지 않는 한 무시할 수도 있음.
운영 중인 서버라면 먼저 내부망에 들어가 다른 취약점이나 사회공학으로 재부팅을 유도한 뒤, 이 취약점으로 지속적으로 접근 가능한 셸을 확보해야 할 것임. 2020년에는 영화 같은 공격으로 들렸겠지만 2026년에는 덜 비현실적일 수도 있음.
기사에 나온 도난 상황이나 공급망 공격도 가능함. Secure Boot를 신뢰할 수 없다면 구매자가 막 설치한 하드웨어의 무결성을 얼마나 검증할 수 있을지 모르겠음.
실제 취약점이라고 해서 인터넷 전체가 15분 만에 해킹되는 것은 아님. 이런 공격을 성립시키려면 여러 공격 단계를 연쇄적으로 연결해야 함.
기사에 따르면 로컬 네트워크에 대한 일정 수준의 통제가 공격의 전제조건임. 따라서 내부자나 국가 차원의 공격자, 랜섬웨어 조직처럼 이미 내부망에 접근해 시스템 권한을 높이려는 공격자로 악용 범위가 제한될 가능성이 큼.
PXE 부팅 자체가 워낙 취약한 과정이라 이번 일이 세상의 종말처럼 느껴지지는 않음. 특정 대상을 겨냥한 ICMP 패킷을 보낼 만큼 네트워크에 접근한 공격자라면, PXE 부팅 서버를 다른 방식으로도 건드릴 수 있을 가능성이 매우 높음.
일부 보안 전문가들이 계속 늑대가 나타났다고 외치다가 결국 아무도 귀 기울이지 않게 만드는 꼴임.
실제로 얼마나 악용하기 쉬운 취약점인지 궁금함. 먼저 장치가 PXE 부팅을 해야 하는데, 내가 설정한 거의 모든 장치는 고정 저장매체에서 먼저 부팅함. 재부팅도 강제해야 하고, 공격자가 접근 가능한 네트워크에 있어야 함.
PXE로 부팅하는 장치가 많기는 하지만, 외부에 공개된 장치를 굳이 그렇게 설정할 이유가 무엇인지 모르겠음.
대부분의 네트워크 부팅 환경에서는 쉽게 해결할 수 있을 듯함. 다만 관리 목적으로 네트워크 부팅을 설정한 기업용 노트북은 애매함. 이 경우에는 공격자가 네트워크와 부팅 시점을 통제하기가 갑자기 쉬워질 수 있음.
http2shell과 php2shell은 모두 실제 악용이 매우 어려움. 심각하지 않다는 뜻은 아니고 패치도 해야 하지만, 뉴스가 묘사하는 종말 같은 상황은 아님. 이번 취약점도 비슷한지 궁금함.
기사에 따르면 이미 회사 내부망에 접근한 공격자만 악용할 수 있음. 제대로 구성된 환경에서는 서버 관리용 이더넷 인터페이스에 별도 망을 사용하고, 허가되지 않은 컴퓨터의 접근을 막으며, 서버의 네트워크 부팅도 그 망에서 수행함.
따라서 회사 내부자나 이미 내부 컴퓨터를 장악한 외부 공격자만 악용할 수 있음. 관리망이 분리되어 있다면 내부자는 관리자여야 하고, 외부 공격자는 관리자 컴퓨터를 장악해야 함.