구글이 인텔 중앙처리장치(CPU) 펌웨어의 보안취약점을 근본적으로 없애기 위한 대체 소프트웨어(SW)를 개발 중이다. 인텔칩 기반 PC나 서버 제조사의 업데이트를 받는 게 펌웨어 문제를 해결하는 유일한 해법이었던 상황이 앞으로 달라질 수 있을지 주목된다.
인텔은 지난 20일 보안권고를 통해 회사의 CPU 펌웨어 3종에서 보안취약점 8건을 찾았고 그 절반인 4건이 매니지먼트엔진(ME)이란 펌웨어에 있었다고 밝혔다. 잠재적 보안 위협을 해결하려면 각 PC 및 서버 제조사가 배포하는 업데이트를 적용하라고 조언했다. [☞관련기사]
인텔칩 기반 PC와 서버 사용자가 ME 펌웨어의 보안 결함에 따른 잠재적 위협으로부터 보호받으려면 전적으로 제조사에 의존해야 한다. 이는 인텔이 ME 펌웨어를 개발하고 배포하는 방식에 따른 제약이다. ME는 오픈소스 운영체제(OS) 미닉스(MINX) 3 버전의 변종이지만, 그 소스코드는 비공개다. ME의 전체 동작 방식, 구성요소, 코드의 물리적인 위치와 논리적인 구동 범위도 명확히 밝혀진 바 없었다.
ME처럼 동작 방식이 불분명하고 입력되는 정보가 어떻게 처리돼 어떤 결과로 이어지는지 불투명한 SW를 업계에서는 때때로 '블랙박스'라고 부른다. 블랙박스형 SW는 문제를 일으켜도 사용자가 직접 원인을 파악해 조치하기 어렵고, 공급자 이해관계 때문에 사용자 이익에 반하는 동작을 숨겨뒀을 수 있다는 점에서 보안관리에 불리한 측면이 있다.
업계는 ME라는 블랙박스로 제어되는 인텔CPU가 이 프로세서를 탑재한 전체 시스템과 사용자에게 상당한 보안 위협을 야기할 수 있다고 지적해 왔다. 이미 지난 5월 ME를 기반으로 구동되는 인텔CPU 기능 액티브매니지먼트테크놀로지(AMT) 기능에서도 취약점이 발견됐다.
구글도 세계 각지에 운영 중인 대규모 클라우드 데이터센터용 서버의 CPU를 거의 인텔에 의존하고 있어, 블랙박스인 ME 펌웨어에 보안 결함이 발생하면 구글에도 골칫거리가 된다. 그래서 구글 엔지니어 로널드 미니치(Ronald Minnich)는 동료들과 함께 ME 펌웨어의 기능을 최소화해 인텔CPU 기반 시스템에 가중될 수 있는 잠재적 보안위협을 최소화하는 방법을 연구해왔다. 그 중간 성과가 약 1개월전 공개됐다.
결론부터 말하면, 구글은 이 연구를 통해 통해 불필요한 ME 펌웨어 기능과 부팅전 동작을 모두 제거하고 리눅스의 성능, 안정성을 갖춘 대체 펌웨어를 쓸 수 있게 됐다. 이걸로 데이터센터용 오픈소스 하드웨어 규격인 오픈컴퓨트프로젝트(OCP) 기반의 인텔CPU 기반 리눅스서버에서, 과거 셸프롬프트를 띄우기까지 8분 정도 걸렸던 부팅 시간을 17초로 단축했다. [☞발표자료 원문보기(PDF)]
이는 지난달(10월) 하순 체코 프라하에서 열린 '임베디드 리눅스 컨퍼런스 유럽' 현장에서 발표된 내용이다. 사실 지난주 주요 외신과 최근 지디넷코리아가 보도한 인텔 ME 펌웨어 관련 기술적 분석 내용 가운데 상당 부분이 이 발표를 통해 밝혀진 것이었다. [☞관련기사]
미니치의 발표는 '여러분의 취약점 악용소지가 다분한 펌웨어를 리눅스 커널로 대체하기(Replace your exploit-ridden firmware with a Linux kernel)'라는 제목으로 진행됐다. 미니치와 동료들이 ME를 분석한 결과와 그 보안 문제를 줄여보고자 개발한 기술을 소개한다.
■인텔CPU 펌웨어에 숨은 3가지 OS
미니치의 발표에 따르면 인텔CPU 컴퓨터엔 사용자를 위한 OS와 별개로, 사용자가 존재를 의식하지 못하는 3가지 OS가 있다. 이번에 보안취약점을 드러낸 ME가 그 하나고, 바이오스(BIOS) 영역에서 실행되는 시스템관리모드(SMM)와 통합확장펌웨어인터페이스(UEFI)가 나머지 2가지다. 미니치는 인텔CPU 컴퓨터의 ME와 SMM과 UEFI, 3가지 OS가 모두 저마다 잠재적 보안위협 요소를 내재하고 있다고 분석했다.
컴퓨터 안의 SW코드를 그 실행에 필요한 권한과 시스템 핵심요소에 접근할 수 있는 단계에 따라 분류할 수 있다. 링(Ring)이란 문자에 숫자를 붙인 표기로 분류를 나타낼 수 있는데, 숫자가 낮을수록 높은 권한을 갖고 핵심 영역을 다루는 코드로 보면 된다. 미니치는 이 분류방식에 따라 ME, SMM, UEFI의 동작이 어떤 단계에서 이뤄지는지 설명했다.
간단히 보면 사용자가 볼 수 있는 건 일반 애플리케이션(Ring 3)과 그게 돌아가는 사용자 OS(Ring 0), 그리고 이 OS를 가상화하는 SW(Ring -1) 정도다. ME는 사용자는 모르지만 인텔CPU는 그 동작을 인식할 수 있는 CPU 자원 제어(Ring -2), 그리고 시스템을 켜고 끄거나 인텔CPU 모르게 전원이 차단된 컴퓨터의 디스크 이미지를 재구성(Ring -3)할 수 있다.
ME가 링 -3단계의 OS라면, SMM과 UEFI는 링 -2단계의 OS 역할을 반(½)씩 나눠 맡고 있다.
SMM은 오래된 16비트 마이크로프로세서(인텔 8086)용 코드의 통로고, 시스템관리인터럽트(SMI) 공격에 취약하다. 하지만 인텔의 칩셋은 한 번 SMM을 설치하면 이후 동작 단계에서 D램의 상위 8MB 크기 영역을 숨겨버리기 때문에, 사용자나 관리자는 그 코드를 바꾸기는 커녕 열어서 들여다볼 수도 중지할 수도 없다. SMM은 제조사가 사용자 시스템 통제를 지속하는 역할을 한다.
UEFI는 메인 CPU에서 구동되고 복잡한 커널을 지녔으며 수백만줄의 코드로 구성돼 있다. 부팅이 완료된 뒤 UEFI 애플리케이션이 구동되는데 보안모델이 불명확하다. 다양한 시스템 기능에 접근할 수 있는 컴포넌트를 포함한다. 취약점이나 버그를 고치려면 UEFI 스스로 재작성(rewrite)하는 동작을 실행해야 하는데, 이는 오히려 가짜로 꾸민 공격코드 제거 프로세스에 당할 수 있다.
미니치의 설명대로라면 ME, SMM, UEFI같은 펌웨어 수준의 코드는 서로 맞물려 사용자에게 안 보이게 숨어서 동작하며 전원 공급 여부에 구애되지 않고 스스로 코드를 변경하거나 재설치 가능한 권한을 갖고 있는데 보안에 취약한 버그가 많다. 인텔CPU 설계상 리눅스같은 오픈소스 SW 사용자에게조차 온전한 통제 권한을 주지 않아, 잠재적 보안 구멍인데다 문제 발견시에도 대처하기 어렵게 만드는 걸림돌이다.
■구글 '너프(NERF)' 프로젝트
미니치는 이처럼 문제가 많고 폐쇄적인 인텔CPU ME 펌웨어의 세부 구성요소를 파헤쳐서 가능한 많은 기능을 분석한 다음 그 전반적인 동작을 사용자에게 투명한 리눅스OS의 영역으로 되가져오기로 했다. 그의 분석 결과 인텔CPU ME 펌웨어 자체를 전혀 쓰지 않고 완저히 걷어내는 것은 거의 불가능하지만, ME를 매개하는 구성요소 대부분은 제거할 수 있는 것으로 파악됐다.
미니치와 다른 개발자들은 이를 위해 '확장불가 축소 펌웨어(Non-Extensible Reduced Firmware, NERF)'를 개발하고 있다. NERF 프로젝트는 UEFI 펌웨어 기능 대부분을 구글이 고(Go) 프로그래밍 언어로 코드를 손본 작은 리눅스 커널과 '초기 램 파일 시스템(initial RAM file system, initramfs)'으로 대체하는 작업이라는 게 오픈소스SW 관련 소식을 다루는 사이트 포로닉스에 게재된 설명이다. [☞원문보기]
미니치의 발표자료에 언급된 NERF의 개발목표는 다음 6가지였다.
첫째, 해로운 동작을 할 수 있는 능력을 덜어낼 것. 둘째, 동작을 더 가시화할 것. 셋째, 없애기 힘든 ME 펌웨어 자체를 제외한, 웹서버 및 IP스택 등 모든 런타임 구성요소를 제거할 것. 넷째, UEFI의 IP스택과 다른 드라이버도 제거할 것. 다섯째, ME와 UEFI의 자체 덮어쓰기(self-reflash) 기능을 없앨 것. 여섯째, 펌웨어의 플래시 업데이트를 리눅스에서 관리할 것.
미니치는 이를 위한 NERF의 구성요소로 다음 5가지를 열거했다.
첫째, 얼룩(불확실한 구성요소)을 제거한 ME 롬(De-blobbed ME ROM). 둘째, 기본적인 부분만 남기고 축소한 UEFI 롬. 셋째, 비활성화 또는 리눅스로 연동된 SMM(SMM disabled or vectored to Linux). 넷째, 리눅스 커널. 다섯째, 고 언어로 작성한 사용자 환경(Userland written in Go).
구글 엔지니어들은 몇 가지 개발 과정상의 제약을 확인했고, 위 5가지 구성요소를 통해 최종적으로 인텔CPU 메인보드의 UEFI를 대신할 기능과 프로그램 코드를 구현할 수 있었다.
■리눅스커널의 성능·보안성, UEFI로 이식
구글이 링 -3 단계의 구성요소를 처리하려고 보니 ME 자체를 완전히 없애는 건 까다로운 일이었다. ME를 잘못 건드리면 아예 인텔CPU 하드웨어 전체가 먹통이 되거나 정상 동작을 하지 않았기 때문이다. 구글은 대신 웹서버, IP스택, 기타 작업을 수행하는 코드를 걷어낼 수 있었다. 이번에 ME와 함께 취약점이 발견된 서버플랫폼서비스(SPS) 펌웨어 쪽에는 이를 적용하지 못했다.
링 -2 단계의 구성요소인 SMM은 어떻게 됐을까. 구글은 커널 핸들러에 직접 SMM 인터럽트를 수행하는 기능을 실험하고 있다. 이게 구현되려면 SMM이 설치되기 전에 커널이 실행되거나 SMM이 아예 설치되지 않아야 한다. 구글은 SMM을 아예 없애는 시나리오를 검토 중이다.
링 -2 단계에서 나머지 '반쪽'인 UEFI의 처리는 어땠을까. 간단히 줄이면 구글은 UEFI의 수많은 구성요소를 걷어냈다. 그게 동작하던 BDS, TSL, 런타임, AL 등 UEFI 부팅 후반부 절차를 재구성했다. DxeCore라 명명한 드라이버 디스패처 대체코드 동작, 리눅스커널로 변경한 부트매니저, 고 언어 기반의 오픈소스 루트 파일시스템 'u-root'의 실행으로 연결했다. [☞깃허브 u-root 프로젝트 바로가기]
구글은 u-root 소스에 기반한 루트 파일시스템 '유저스페이스(Userspace)'로 NERF 구현을 위한 initramfs을 만들었다. initramfs는 컴퓨터 안에서 리눅스 부팅 과정의 일환으로 임시 루트 파일시스템을 메모리에 불러오는 동작을 구현하는 방식 중 하나다. 실제 루트 파일시스템이 리눅스에 마운트될 수 있도록 그 전에 준비하는 역할을 한다.
구글의 유저스페이스는 5.9MB 크기에 모든 소스관련 명령어와 고 언어 컴파일러 및 패키지 소스, 툴체인을 포함했다. 최초 사용 또는 부팅 시점에 명령어가 컴파일을 수행하며 빌드에 200밀리초, 실행에 1밀리초 걸린다. 소스코드 가시성이 있어 보안상 유리하다. 펌웨어 공간이 작을때 쓸만한 2MB짜리 단일 프로그램 버전도 만들었다.
관련기사
- 보안 구멍난 인텔CPU, 예견된 사고였다2017.11.30
- 리눅스 창시자 토발즈 "보안이 프로세스 죽이지 말아야"2017.11.30
- 인텔CPU, 심각한 보안결함…"수백만 기기 취약"2017.11.30
- 인텔, 2020년 BIOS 지원 중단2017.11.30
미니치의 자료에 따르면 유저스페이스를 통해 컴퓨터 기동에 필요한 모든 초기화(init) 스크립트를 고 언어 기반 프로그램으로 대체했다. systemd, upstart, scripts 프로그램은 불필요해졌다. 이를 위해 구동속도가 매우 빠른 고 언어 기반 바이너리를 맞춤제작했다. 크롬OS를 u-root 기반으로 개조한 '니크롬(NiChrome, 니켈-크롬-철 합금)'을 크롬북에서 돌린 결과 불과 5초만에 부팅후 X윈도시스템(x11)과 브라우저까지 띄웠다.
이상의 리눅스커널을 활용한 인텔CPU 펌웨어 대체기술 개발작업은 아직 마무리된 게 아니다. 미니치는 NERF 프로젝트 결과물을 테스트 및 이식하는 작업과 문서화 등 여러 외부 참여자의 도움이 필요한 상황이라고 밝혔다. NERF 프로젝트는 구글의 미니치와 외부 개발자인 트래멀 허드슨의 협력으로 진행되고 있다. 허드슨의 NERF 소개 페이지를 통해 세부 정보와 현황을 확인할 수 있다. [☞바로가기]
