요약
서버 펌웨어의 바탕 코드인 EDK2에서 부팅 초기에 악성 코드를 실행할 수 있는 취약점이 드러났습니다.
아르스테크니카의 댄 구딘 기자가 전한 소식입니다. 앤트로픽과 구글의 연구자가 찾아 1월에 공개하려던 취약점인데, AMI가 지난달 수정 코드를 먼저 올리면서 일정보다 일찍 알려졌습니다.
왜 중요한가
- AMI를 비롯한 거의 모든 UEFI 공급사가 EDK2(오픈소스 기준 코드)를 써서 영향 범위가 서버 대부분에 이릅니다.
- 수정 코드가 이미 공개돼 공격법을 알아내기는 쉽지만, 수많은 기기의 펌웨어를 고치는 데는 오래 걸립니다.
- HD 무어는 이 취약점으로 TPM(암호 키를 지키는 보안 칩)에 접근해 디스크 암호화를 깰 수 있다고 경고했습니다.
핵심 내용
- CVE-2026-97631은 심각도 9.5점(10점 만점)으로, 네트워크 부팅 드라이버에 16년간 숨어 있던 버퍼 오버플로입니다.
- PXE 부팅(네트워크에서 부팅 코드를 받아 시작하는 방식) 중 504바이트 칸에 ICMP 오류 메시지를 넘치게 복사합니다.
- 조작한 메시지 하나로 운영체제와 Secure Boot보다 먼저 최고 권한(링 0)에서 코드를 실행할 수 있습니다.
- 다만 내부 네트워크에 접근해야 하고 기종마다 메모리 주소를 맞춰야 해서 대량 공격은 어렵습니다.
- 디스크로만 부팅하는 가정과 소규모 사무실은 해당하지 않고, 기사는 네트워크 부팅을 잠시 끄라고 권했습니다.
HN 반응
- 일부 이용자는 거대한 범용 코드 대신 용도에 꼭 맞는 작은 펌웨어를 써야 한다며, 약 100만 줄의 C 코드를 어셈블리 300줄로 바꾼 사례를 소개했습니다.
- 코드를 줄이려다 외부 패키지 의존이 늘 수 있다는 반론에는, 남의 패키지도 공격 면을 넓히기는 마찬가지라는 재반론이 붙었습니다.
저희는 최근에 OVMF(C 코드 약 100만 줄)에서 벗어나, 특정 기밀 VM 대상에만 맞춘 아주 작은 전용 펌웨어(어셈블리 300줄)로 옮긴 이야기[1]와, "많이 쓰인다"는 것이 곧 "안전하다"는 뜻은 아니라는 이야기를 글로 썼습니다. 어떤 대형 코드베이스든 LLM에 들이대면 취약점을 찾아내니, "전 세계를 패치한다"는 방식은 확장성이 떨어집니다. 대신 특정 용도에 맞춘 작은 코드베이스를 직접 만들고, LLM(코드가 작으면 비용도 적게 듭니다), 퍼징, 형식 검증 같은 보안 기법을 모조리 쏟아부을 수 있습니다.
[1] https://tinfoil.sh/blog/2026-10-25-less-is-more
저도 비슷하게 생각해 왔습니다. 공격 표면을 줄이려면 우리가 만드는 프로그램의 의존성과 코드 크기를 최소화해야 하는 시대가 곧 올 겁니다.
하지만 오히려 의존성 지옥으로 더 깊이 빠져들 수도 있습니다. 버그와 공격 표면이 늘어나는 위험을 감수하는 대신, 단순한 작업을 해 주는 패키지를 찾게 될 테니까요. 그 패키지가 이미 검증됐다고 가정하고, 그 패키지의 의존성도 끝까지 다 그렇다고 가정하면서요.
코드를 작게 유지하려다가 일을 더 많이 떠넘기는 의존성이 불어나 역효과가 날 수 있습니다.
아니요, 신뢰할 수 없는 입력에 노출되는 "단순한 작업을 해 주는 패키지"를 추가하면 "버그와 공격 표면"이 늘어납니다. 그건 "버그와 공격 표면을 늘리는 것"의 대안이 아니에요. 코드를 작게 유지하려는 사람들은 의존성의 4000줄짜리 코드 대신, 필요한 것만 하는 자기 코드 400줄을 선택할 겁니다.
원글 작성자가 코드를 작게 유지한다고 할 때는 의존성까지 포함한 모든 코드를 말하는 거라고 거의 확신합니다.
한 가지 일만 하고, 그걸 잘 하라.
유닉스 철학이 승리하는군요!
아, 그 유명한 책 속 명언이죠. 실제 UNIX 시스템에서는 본 적이 없지만요.
xz에 링크하기 전까지는 그렇죠.
systemd가 얽힌 건 더 이상 유닉스 철학과 관련이 없다고 자신 있게 말할 수 있습니다.
init 기반 시스템에서 systemd로 넘어가면서 트라우마를 입은 사람이 많다는 건 압니다. 하지만 다양한 시스템 프로세스를 관리하는 일이 원래 복잡하다는 점을 감안하면, 그 구조는 탄탄하고 비교적 단순합니다.
추가: "한 가지 일만 하고 잘 하라"에 정면으로 반하는 유닉스의 안티 히어로를 찾는다면(systemd보다 먼저 나왔습니다) emacs만 한 게 없습니다.
그래요, 유닉스 철학은 엔지니어링 부서에서 나온 거지, 회계 부서에서 나온 게 아니니까요.
광고나 도파민 해킹, 허공에 대고 하는 후원 구걸 없이, 또 유권자에게 영향을 미치려는 억만장자의 보조금 없이 FOSS 프로젝트에 자금을 대는 문제는 여전히 대체로 풀리지 않았습니다.
문제는 방법을 모른다는 게 아닙니다(해결된 문제예요. UBI, 적은 노동에 더 높은 임금, 높은 한계소득세율, 일정 금액 이상 미실현 자본이득세, 토지세 등등).
문제는 억만장자도 아닙니다.
문제는 안락하고 야심 있는 중상위 소득자들을 설득하는 겁니다. 더 높은 바닥이 주는 안정(그리고 그 뒤에 이어지는 혁신의 토양 다지기)을 얻는 대신, 자신과 자기 상사들이 얻을 수 있는 전망에 상한을 두라고 말이죠.
이들이 걸림돌인 이유는, 대체로 집단적으로 현상 유지를 눈감아 주고 가능하게 할 돈과 투표권을 쥔 사람들이 바로 이들이기 때문입니다.
문제의 일부는 그중 일부가 아니라 전부가 좋은 생각이라고 믿는 사람들이 있다는 겁니다.
높은 한계세율과 미실현 이익 과세는 둘 다 의도치 않은 결과를 양산하는 공장입니다. 특히 후자가 그렇지만, 전자도 결국 왜곡된 유인과 차익거래 기회(즉 거대한 허점)를 만들어 내느냐, 아니면 높은 세율이 모든 것에 적용되는 바람에 해외 이전을 부추기느냐 사이의 맞교환이에요. 높은 세율이 모든 것에 적용되지 않으면 앞의 문제가, 적용되면 뒤의 문제가 생기니까요.
반대로 UBI는 좋은 생각이고, 기존 정부 복지와 보조금 제도의 대부분을 대체하기 때문에 억압적인 세율이 사실 필요하지 않습니다. 그 제도들은 수급 자격이 단계적으로 줄어드는 방식으로, 중산층 대다수에게 더 높은 사실상의 한계세율을 부과하고 있거든요. 미국 연방 지출은 이미 1인당 2만 달러가 넘습니다.
전부가 지원 프로그램은 아니지만 상당 부분이 그렇습니다. 그리고 그런 프로그램 대부분은 예산을 UBI로 돌리는 것에 비하면 순손실입니다. 식비 지원, 주거 지원, 교육 지원 등을 따로따로 운영하는 관료 조직을 두는 건, 그것들이 이상한 한계세율 절벽을 만들고 임의로 겹치는 수급 감소 구간 때문에 저소득층에 더 높은 한계세율을 물리기 전부터 이미 어리석은 일입니다.
문제는 돈의 출처가 아닙니다. 이것들을 UBI로 바꾸면 행정에 쓰던 돈을 아낄 수 있어서 더 적은 돈으로 사람들에게 더 많은 돈을 줄 수 있고, 쓰임새에 임의의 제약을 두지 않으니 경제적 효율도 높아집니다. 그렇게 하지 못하는 주된 이유는 중상류층이 자기 이익을 위해 현상 유지를 요구해서가 아닙니다. 그들의 이익에도 맞지 않으니까요.
그저 평범한 무능과 잘못된 구조적 유인이 합쳐진 결과입니다. 정치인은 모두가 받는 현금 지급액을 1인당 GDP에 연동해 지급하고 집으로 돌려보내는 대신, 새 프로그램을 만들어 생색내는 걸 좋아하니까요.
그건 애초에 유닉스 선전에 불과했습니다. GNU가 등장해서 더 높은 기준을 세우기 전까지는, 유닉스 도구들이 입력을 고정 길이 줄 버퍼로 읽어 들이고 그보다 긴 건 조용히 잘라 버리는(노골적으로 죽지 않을 때의 이야기입니다) 헛짓을 하는 게 흔했어요. "잘 하라"라니, 어림도 없죠. "유닉스 철학"을 더 현실에 맞게 설명하자면 "worse is better"입니다. 좋을 필요는 없고 그냥 쓸 수만 있으면 된다는 거죠.
GNU 프로그램도 "echo -e"와 "cat -n"을 시작으로 awk와 sed 같은 도구까지 못하는 게 많습니다. 유닉스 철학은 GNU보다 Powershell이 더 잘 구현합니다.
그래도 군더더기 없는 인터페이스와 도구 범위로 기능이 계속 불어나는 걸 막겠다는 건 여전히 꽤 괜찮고 야심 찬 목표입니다. (파이프라인을 통한) 조합 가능성도 상당히 잘 작동하고요. 하지만 네, 어느 정도는 선전이 맞습니다.
군더더기 없는 인터페이스는 동작이 엄청나게 잘 명세되어 있지 않으면 쓰기가 정말 골치 아픕니다.
GNU 재구현체들은 64K 주소 공간에서 돌아가야 한다는 걸 신경 쓰지 않아도 될 만큼 늦게 나왔죠.
올해는 마이크로커널의 해입니다.
정확히는 유니커널과 그 너머죠. 미래는 가상화된 베어메탈 위에서 라이브러리 의존성을 최소화한 채 돌아가는 작은 단일 목적 프로그램입니다.
70년대 소프트웨어는 클로즈드 소스 맞춤형 재구현, 80년대는 재사용 가능한 소프트웨어 컴포넌트라는 꿈, 90년대는 그 꿈을 짓는 시기, 00년대는 그 꿈을 사는 시기, 10년대는 다 놀랍긴 한데, 20년대는 전환기..., 30년대는 뭘까요??? 오픈{소스, 레퍼런스 구현, 테스트, 명세, 설계 문서, gist, ...?} 맞춤형 재구현일까요?
중국 특색(中国特色)입니다. 그리고 제약 업계에 최적화된 미국의 IP 체계(Industrial Policy, 산업 정책)와는 격차가 훨씬 더 큽니다.
음악 한 곡 듣거나 동료, 친구와 채팅하는 데 브라우저를 통째로 띄우고 각각 램을 몇 기가씩 먹는 형편없는 데스크톱 웹 앱을 쓰면서 우리가 꿈을 살고 있다고는 못 하겠네요. Electron 같은 것들은 소프트웨어 세계의 재앙입니다.
LLM과 반도체 부족이 네이티브 애플리케이션의 르네상스를 불러온다면 좋겠습니다.
그렇다면 패키지, 중앙 저장소, 패치 없이 그냥 되는 다운로드, 공개 버전 관리 시스템, 오픈 소스 소프트웨어 ... 그리고 그것들이 가능하게 한 많은 것들을 포기하실 건가요?
"문명은 우리가 생각하지 않고도 수행할 수 있는 중요한 작업의 수를 늘림으로써 진보한다." - 앨프리드 노스 화이트헤드, 수학 입문(An Introduction to Mathematics) (1911)
2026년의 비행기 좌석에 구겨 앉는 건 "비참한 경험"일 수 있습니다. 하지만 당연하게 여기는 그 인간의 비행, 그러니까 망할 구름 속의 좁은 좌석은 대체 뭘까요? 한두 세기에 걸친 집중적인 노력, 나중에는 엄청난 노력으로 그 꿈을 일군 결과 아닌가요? 컴팩트한 기계 동력이라는 꿈을 좇은 또 한 세기, 금속공학에 쏟은 1만 년은요? 그러니 비행이 형편없었을 수 있고 항공이 존재해서 생기는 단점도 많지만, 인간 비행이라는 꿈을 산다는 건 문제가 하나도 없고 영원히 행복하기만 한 꿈 속에서 산다는 뜻이 아닙니다.
하지만 네, 저는 에이전트가 풀스택 수준으로 다시 짜서 수십 년간 쌓인 정체된 군더더기를 쓸어내는 게 정말 기대됩니다. 노트북 수준의 각해상도를 가진 HMD가 올해쯤 나옵니다(비싸고 대중 시장용은 아니지만요). 그리고 그런 재작성을 손으로 하는 건 고역이고요. 어떤 사람은 Claude가 한 번에 PICO Space Pro 개발 환경을 설치하고, 간단한 앱을 만들고, apk를 헤드셋에 올린 다음 "테스트할 준비가 됐습니다"라고 답했는데 정말 그랬다고 보고합니다. 엄청난 변화가 오고 있어요. 다만 그게 말씀하신 미니멀하고 효율적인 르네상스는 아닐지도 모르겠네요. 그래도 혼란의 한가운데에는, 더 안정된 시기에는 실현하기 어려웠을 비전을 좇을 기회가 있습니다.
자바스크립트와, 그걸로 해선 안 되는 일을 하는 사람들이 문제의 핵심입니다.
자바스크립트가 아니었어도 다른 무언가가 그랬을 겁니다. 이 목록에서 제일 느린 기기가 뭔가요? https://danluu.com/input-lag/
그리고 빠른 경로도 있을 수 있습니다. evdev를 직접 지켜보면서 일반적인 X11 윈도 매니저 아래 전체 화면으로, 60Hz나 120Hz 이상으로 빠른 디스플레이에서 돌거나 vsync를 무시하는 electron 앱이라면... 꽤 날렵할 수 있어요.
문제의 핵심은 수익 유인과 탐욕에 기반한 경제입니다. 우리 사회는 일반 대중에게 최고의 제품과 서비스를 제공하도록 설계된 게 아니라 가치를 뽑아내도록 설계되어 있어요.
아, 네.
어디를 봐도 구조적 문제라는 거죠, 우디!
저는 이 300줄(어셈블리) 대 약 100만 줄(C)이라는 발상이 정말 마음에 듭니다. 자기가 하는 일을 제대로 이해하고 필요한 핵심 기능으로 범위를 제한하니 가능했던 일이겠죠. 이번 경우에는 저수준 코드라서 '그럴 여유'가 있었던 셈이고요. 제가 걱정하는 건 프레임워크, 런타임, 인터프리터 위에서 돌아가는 모든 (애플리케이션) 코드입니다(최근 PHP 논란을 염두에 두고 하는 말입니다). 애플리케이션 코드를 아무리 단단히 만들어도 밑에 깔린 코드가 안전하지 않으면 문제가 생깁니다. 공격자가 방어자보다 유리하다고 하신 말씀과 합치면 더 그렇고요. 지금으로서는 이를 지킬 방법이 어떤 형태의 (가상) 사설 네트워크를 쓰는 것뿐인 것 같습니다. 이에 대해 어떻게 생각하시나요?
이게 제가 systemd에 가장 불만인 점 중 하나입니다. 수백만 줄의 코드. 엄청난 복잡성. 끊임없는 변경. 끝없는 설정 변경(그 때문에 낡고 잠재적으로 위험한 설정이 생깁니다).
Sysvinit은 1000줄, 많아야 조금 더 되는 정도입니다. systemd에 비하면 바위처럼 단단하죠.
정말 많은 개발자가 큰 코드베이스를 전혀 문제 삼지 않습니다. 어떤 사람들은 node와 composer 패키지 1000만 줄을 끌어다 쓰면서도 "작다"를 "작아 보인다"로 바꿔치기하고요.
그리고 물론 새로운 목표는 Lennart의 새 회사 일자리와 함께 Linux에 "신뢰 컴퓨팅", 이를테면 Microsoft식 EEE를 들여오는 겁니다.
하지만 세상이 달라졌습니다. 그러니 뭘 할 수 있겠습니까?