21세기 최악의 스켄들로 기록될 수 있는 CPU 게이트, 멜트다운과 스팩터 버그에 대해서..

난데없이 터진 CPU 게이트

요즘 CES 2018이 미국 라스베가스에서 열리고 있는데 웃기는 것은 CES보다 CPU 버그에 대한 이슈가 더 높아서 CES(오죽하면 CES를 CPU Error Session이라고 말할까.. ㅎㅎ)에 대한 관심은 저 멀리 떠나가고 있는 것처럼 보인다. 무슨 얘긴가 하면 구글이 2018년 1월 3일에 공개한 멜트다운 및 스펙터 버그에 대한 내용이다. 이는 특정 CPU 설계에서 발생된 2개의 중대한 보안 취약점으로 구글 프로젝트 제로에서 처음으로 발견해서 공개한 이슈다(어떤 CPU인지는 밑에서 얘기하도록 한다).

이 버그가 공개된 과정도 웃긴 것이 원래는 구글측에서 2017년 중반쯤에 발견했다고 하고 그것을 MS와 리눅스 개발진에게 알려서 보안 패치 등 필요한 작업을 한 뒤에 2018년 1월 9일에 공개할 예정이라고 했는데 리눅스 패치를 지켜보던 사람들이 뭔가 낌새를 눈치채 2018년 새해에 인텔 CPU에 뭔가 심각한 버그가 있다는 것이 소문으로 알려지고 그것 때문에 구글은 1월 9일이 아닌 1월 3일에 이 내용을 발표하게 되었다. 참고로 패치 작업에 대해서는 엠바고가 걸려있는(즉, 무슨 내용인지 공개하지 않는) 상태로 비밀리에 진행이 되었는데 커널 개발자들이 관련 내용을 패치하면서 주고받은 이메일에 참조로 인텔, 구글, 아마존의 관계자들의 메일 주소가 있고 인텔 CPU가 위험하다는 플래그(메일에 플레그를 달아놓은 듯)가 있는 것을 보고 수상한 작업을 눈치했다고 한다. 그래서 예정보다 일찍 공개되었다(고 나무위키에 적혀 있다 ^^).

이 버그는 멜트다운(CVE-2017-5754) 버그, 그리고 스팩터(CVE-2017-5715, CVE-2017-5753) 버그라고 명명이 되었으며 영향을 받는 OS들이 현재 패치를 만들어 배포하고 있는 상황이다. 그렇다면 그 멜트다운과 스팩터 버그에 대해서 조금 더 살펴보자. 참고로 이미 다 나와있는 정보들을 정리해놓은 수준이니 너무 기대는 하지 마시라.. ^^;

멜트다운과 스팩터 버그의 원리

예측 실행과 분기 예측

CPU 제조사들은 CPU의 처리속도를 향상시키기 위해 다양한 기술들을 CPU 제조에 적용시키기 시작했는데 그 중에 하나가 이 멜트다운과 스팩터 버그와 관련이 있는 예측 실행(Speculative Execution)과 분기 예측(Indirect Branch Prediction) 기술이다. 알려지기로는 이 기술들은 20년전(1995년)부터 사용되기 시작했다고 한다.

일단 이 기술을 설명하자면 원래 프로세서는 한가지 명령에 대한 처리가 끝나면 다른 명령을 받기 전까지는 아무런 작업을 하지 않도록 되어 있지만 속도 향상을 위해 최적화 기술을 개발하면서 미리 실행될 가능성이 높은 명령을 예측하여 그 명령을 처리하기 위해 필요한 데이터들을 CPU 캐시에 미리 저장해두기 시작한다. 즉, 명령어 1을 실행하면서 다음에 실행 가능성이 높은 명령어 2에 대해서 명령어 2를 실행하기 위해 필요한 데이터들을 캐시에 저장해둔다. 명령어 1이 끝나고 명령어 2가 실행되면 미리 저장해둔 데이터들을 기반으로 명령어 2가 실행되고 동시에 다음에 실행가능성이 높은 명령어 3에 대한 필요 데이터들을 캐시에 저장해둔다. 명령을 실행할 때 데이터를 읽어서 실행해야 하는데 그렇게 하기 위해서는 데이터를 캐시에 저장하고 그것을 읽어들이는 작업이 필요한데 이렇게 하면 데이터가 이미 캐시에 있기 때문에 저장하는 행위를 건너뛰고 진행할 수 있어서 그만큼 속도가 빨라지는 것이다.

그런데 문제는 예측을 잘못한 경우다. 명령어 2가 실행될 때 명령어 3에 대한 데이터가 미리 캐시에 저장되어 있는데 명령어 2 다음에 명령어 3이 아니라 명령어 5나 6이 실행될 경우, 혹은 명령어 2에 대한 실행에 오류가 생겨 이전 명령인 명령어 1부터 다시 진행해야 할 경우다. 이미 캐시에는 명령어 3에 대한 데이터가 저장되어 있지만 쓰지 못하는 데이터가 되었다. 그렇다면 지워져야 정상인데 캐시에 저장된 데이터가 지워지지 않는다는 것이다. 즉, CPU는 예측 실행으로 인해 저장한 캐시 데이터에 대해서 적합성 여부를 판단하지 않는다는 것이다.

여기서 이 캐시에 남아있는 데이터를 비정상적인 방법으로 접근하거나 권한이 없는 사용자, 혹은 프로세서가 접근하여도 모두 허용하게 되어 그 캐시의 데이터를 열람할 수 있다는 것이 문제다. 해당 캐시에 남아있는 데이터는 관리자 권한으로만 접근이 가능한 데이터도 포함될 수 있는데 관리자가 아닌 권한이 없는 접근을 허용하니 해커들이 맘만 먹으면 해당 내용을 들여다 볼 수 있다는 것이다. 해당 캐시에 남아있는 데이터들은 커널 메모리에 들어있어야 할 데이터들이며 해커들은 일부러 비순차적인 실행 방법(즉, 예측을 벗어난 실행 방법)을 이용해  커널 메모리의 내용을 유출하며 그것을 통해 해킹을 할 수 있다.

멜트다운 버그

멜트다운 버그는 앞서 언급한 해커들이 일부러 비순차적인 실행 방법을 통해 사용자의 커널 메모리를 유출할 뿐만이 아니라 프로세서에 있는 권한 상승 취약점을 공격하는 것을 말한다. CPU의 예측 실행 기능을 이용하면 공격자가 메모리 보호를 우회할 수 있기 때문이라고 한다. 앞서 얘기했듯 해커에 의해 커널 메모리가 유출이 되면 그 안에 존재하는, 즉 시스템 안에 존재하는 보안 매커니즘과 그것에 관련된 다양한 코드 등을 들여다 볼 수 있다는 것이며 그 정보들을 악용하여 보안 매커니즘을 우회하는 공격이 가능하다는 얘기다. 

스팩터 버그

스팩터 버그는 예측 실행 때 실행되어서는 안되는 코드를 실행하도록 유도하여 다른 어플리케이션 메모리 공간에 존재하는 정보를 유출시키게 하는 버그다.

기본적으로 관리자가 아닌 다른 사용자, 혹은 프로세서는 자신이 실행하는 영역의 메모리만 접근이 가능하며 다른 사용자, 혹은 프로세서가 사용하는 영역의 메모리는 접근이 불가능하다. 권한이 없기 때문이다. 하지만 관리자는 사용자, 프로세서에 상관없이 접근이 가능하다. 즉, CPU가 예측 실행으로 먼저 실행하고 그 결과가 조건에 맞지 않으면 버리는 방식을 쓰는데 조건에 맞는지 안맞는지 판단 전에 먼저 실행을 하기 때문에 여기에 해커가 악의적인 목적을 가진 코드를 먼저 실행시키게 해놓는다면(그 안에 다른 예측 실행이 가능하도록 코드를 짠다면) 그 예측 실행에 맞는 데이터가 CPU 캐시에 저장될 것이고 해커는 그 캐시에 저장된 내용을 확보하는 것이다.

그 캐시의 내용은 자신의 프로세스가 아닌 다른 사용자, 혹은 프로세스의 영역을 침범하는 내용이 될 수도 있기 때문에 권한 외 영역의 내용을 가져올 수 있는 버그가 바로 스팩터 버그다.

음식에 비유하자면..

그런데 기술적으로 설명을 하자니 좀 어렵다. 쉽게 설명할 수 있는 방법이 없을까 해서 찾아보니 고려대학교 김승주 교수님의 비유가 참으로 적절해서 허락을 받고 여기에 게시해본다.

<Spectre and Meltdown for Dummies>

1. 해커 A씨는 평상시 흠모하던 B씨의 음식 취향(개인정보)을 알고 싶음.

2. 해커 A씨는 B씨의 단골 식당을 알아낸후, 이 식당의 주방장(CPU)에게 "B씨가 지금 이곳으로 오고 있다"는 거짓 소문을 흘림 (false prediction을 유도).

3. 단골 손님이 오고 있다고 믿은 주방장(CPU)은 신속한 서비스를 위해 줄서있는 손님들 몰래 틈틈히 B씨가 항상 주문하던 음식을 미리(out-of-order execution) 만들어 놓음.

4. 그러나 B씨는 올리가 없고, 후에 이를 알게된 주방장(CPU)은 미리 만들어 놓은 음식을 버려야함에도 불구하고 아까운 나머지 냉장고(cache)에 넣어둠.

5. 해커 A씨는 단골 식당에 전화를 걸어 메뉴에 있는 음식을 차례로 주문해 봄. 이때 유독 빨리 배달되는 음식이 있다면 그것이 미리 만들어 놓은 음식일 확률이 높으며 (side-channel attack의 일종인 cache timing attack), 바로 그 음식이 B씨의 음식 취향(개인정보)임! 물론 중간에 차가 막힌다던지하여 시간의 오차가 생길수 있으나 이러한 noise를 줄일수 있는 방법은 상당히 많이 나와 있음.

이에 대해 재미난 짤도 있는데 하나 가져와본다. 아래의 짤은 본 사람들이 많을 듯 싶다.

출처 : https://mobile.twitter.com/angbffff/status/949562808143785984

피해 범위

멜트다운 버그는 인텔 CPU 및 ARM 코어텍스 CPU 일부에 문제가 되는 것으로 알려져 있으며 스팩터 버그는 인텔, ARM, AMD CPU에서 문제가 되는 것으로 스팩터 버그는 거의 모든 CPU에 문제가 될 수 있음을 알 수 있다. PC나 서버에는 어지간하면 대부분이 인텔 CPU가 들어있기 때문에 AIX, HP-UX와 같은 UNIX 시스템이 들어가는 서버를 제외하고 x86 기반 OS(윈도, 리눅스, macOS 등)를 사용하는 모든 기종은 다 그 피해범위 안에 있다고 봐도 무방하다.

이유인즉, 1995년 이후에 출시된 CPU들에서 이런 기술(예측실행, 분기예측)을 적용했기 때문에 20년전부터 나왔으며 현재 동작하고 있는 서버들이나 PC들은 대부분 그 이후에 만들어졌기에 그렇다. 더욱 ARM도 멜트다운과 스펙터 버그에 노출이 되었기 때문에 iOS를 사용하는 아이폰이나 아이패드 역시 이런 취약점에서 자유롭지 못할 것이라 생각이 든다. macOS는 앞서 언급한 것처럼 당연한 상황이고 말이다.

참고로 멜트다운 버그는 알려진 대로라면 인텔 CPU와 ARM 코어텍스 CPU 일부에 적용되는 것으로 되어 있지만 구글 프로젝트 제로에서 만든 문서에 보면 연구진은 AMD CPU에서도 같은 문제가 나올 수 있다고 얘기하고 있다. 즉, 인텔, AMD, ARM 뭐든 다 이 버그에서 자유롭지 못하다는 얘기다.

해결 방법, 하지만 그것도 문제가..

이를 해결하기 위해 가장 좋은 방법은 CPU 설계를 바꾸는, 즉 디자인을 다시하는 것이라고 한다. OS 패치 등의 소프트웨어 방법으로 당장에는 해결할 수는 있겠지만 근본적인 버그를 갖고 가는, 그것도 하드웨어적인 버그를 안고 가는 것이 문제가 될 수가 있다. 그래서 아예 예측 실행이나 분기 예측 알고리즘을 개선, 혹은 변경한 새로운 디자인의 CPU 설계가 적용된 CPU, 혹은 CPU 펌웨어를 내놓는 것이 가장 좋다. 하지만 현실적으로는 실현이 어렵다는 것이 문제다.

앞서 언급한 것처럼 위의 버그에 영향을 받는 MS의 윈도나 리눅스, 애플의 macOS는 이에 관련한 패치를 발표해서 적용하고 있다. 그런데 패치를 적용한 이후에 여러 애로사항들이 많이 올라오고 있다. 대표적인 문제가 I/O 속도 저하인데 디스크에 읽고 저장하는 횟수가 기존보다 더 많아져 전체적인 속도가 최소 5%에서 최대 30%(어쩌면 그 이상)까지 저하되는 문제가 올라오고 있다. 즉, 디스크에 뭔가를 많이 읽고 쓰는 작업을 하는 어플리케이션은 속도에 있어서 치명타를 입게 되는 것이다.

가장 대표적인 케이스가 데이터베이스 서버로 대용량 DB의 경우 디스크에 자주 저장하고 읽어들이는 작업을 하는데 이 패치로 인해 성능이 기존보다 30%정도 떨어지게 되니 업체들 입장에서는 죽을 맛이다. DB 뿐만이 아니라 클라우드 서비스를 제공하는 업체들도 사정은 비슷하다. 또한 대용량 멀티미디어 파일(영상, 음악, 그림 등)을 다루는 소프트웨어 역시 파일 내용을 자주 읽고 쓰다보니 패치로 인해 받는 악영향이 좀 심각한 것으로 알려지고 있다.

물론 주로 메모리에서 작업을 하는 게임 등은 큰 영향이 없기에 일반 PC에서는 별 문제가 안된다고 알려지고 있고 주로 기업에서 사용하는데 문제가 된다고 알려지고는 있지만 요즘 유튜버들도 많고 집에서 영상 작업을 하는 경우도 많은데 이 패치가 영향을 안줄리는 없을 듯 싶다. 어찌되었던 당장에는 각 OS가 패치를 적용함으로 버그는 해결하고는 있지만 성능저하로 인해 받는 불만은 계속 나올 듯 싶다.

다이나믹하게 돌아가고 있는 IT 세계

성능저하에 대해서는 작년에 애플이 iOS에서 아이폰 7+ 이하 기종에 대해 배터리 성능이 떨어지면 강제적으로 성능을 저하시켰던 해프닝(?)이 있었다. 이것은 개발사가 의도적으로 성능을 저하시킨 케이스로 사전에 사용자들에게 공지를 안했고 선택지도 없었기 때문에 충분이 비난을 받을만 하다. 하지만 이 멜트다운 및 스팩터 버그로 인한 패치 때문에 발생되는 성능 저하는 의도적인 것이 아니라 어쩔 수 없이 진행되는 것이기 때문에 OS 업체나 PC 제조사가 비난을 받는 것은 억울하다. 비난의 대상은 당연히 인텔을 비롯한 CPU 제조사들이어야 할 것이다. 의도는 성능 향상이었지만 어찌되었던 그것으로 인해 버그가 생겼기 때문에 말이다.

작년의 애플의 배터리 게이트에 이어 이번에는 인텔의 CPU 게이트(위의 버그를 CPU 게이트라고 많이들 부르더라)까지 IT 시장이 무척이나 다이나믹하게 돌아가고 있는 듯 싶다. 이것을 과연 관련 업체들은 어떻게 해결할 것인지 더 지켜봐야 할 듯 싶다.

PS) 이건 농담삼아서 하는 얘기지만 멜트다운 버그에 대해서 인텔이 납치했던 외계인이 탈출하면서 인텔 죽어라~ 하면서 남긴 유산이라는 설도 있다.. ㅎㅎ

* 관련 글

인텔 CPU 취약점(Meltdown&Spectre) 분석 및 이스트시큐리티 대응상황 (이스트시큐리티 알약 블로그)

CPU 게이트 (나무위키)

Reading privileged memory with a side-channel (Project Zero)