CPU게이트
[include(틀:상위 문서, top1=보안 취약점)] [include(틀:관련 문서, top1=인텔 관리 엔진)] [Include(틀:다른 뜻1/문단, other1=컴퓨터 공학 용어로 쓰이는 게이트, rd1=트랜지스터, paragraph=2.2.2)] [include(틀:사건사고)] [목차]
개요
하트블리드 이후 2018년 IT계 희대의 사태이자 뜨거운 감자 여러 CPU 제조업체, 특히 인텔에게는 사상 최악의 위기
대부분의 인텔 CPU와 IBM의 POWER CPU, 그리고 ARM 일부 아키텍처에서 발견된 몇 가지 중대한 보안 취약점이 발견된 사건. 2018년 1월 3일 구글에서 최초로 발표하였다.
구글 프로젝트 제로의 얀 호른 수석연구원과 오스트리아 그라츠 공과대학, 그리고 업계 보안전문가들이 처음 발견했다. 얼마 전인 2017년 말에 인텔 관리 엔진 관련 보안 버그가 있었다. 이것도 보안 시스템을 무시하고 시스템을 망가뜨릴 수 있는 치명적인 버그였는데 불과 몇 개월만에 훨씬 위험한 버그가 잇달아 터져서 IT업계 전체가 비상 사태다. 흔한 보안 이슈가 아니라 게이트 소리를 듣는 대사건이다. 특히 인텔 CPU의 경우, 현역으로 사용 가능한 대부분의 제품[* 명령어의 비순차적 실행을 지원하는 모든 제품]이 버그의 위험에 노출되어 50년 역사의 인텔 창업 이래 최악의 위기라는 우려도 나오는 상황이다. 또한 버그 보완 패치의 부작용으로 시스템 콜 성능이 심각하게 저하되어 더 큰 논란이 벌어지고 있다.
알려지게 된 과정
사실 원래 이 버그는 구글의 사이버 보안 연구원 John Horn이 2017년경 매뉴얼을 보다가 [[1]]하여, 마이크로소프트와 리눅스 개발진 등에게 알려 보안 패치 등 필요한 조치를 취한 뒤, 2018년 1월 9일 공개할 예정이었다. 하지만 리눅스 패치를 지켜보던 사람들이 낌새를 눈치채, 2018년 새해 즈음에 공개적으로 '무슨 버그인지는 정확히 모르겠지만 인텔 CPU에 심각한 버그가 있다'는 사실이 개발자들 사이에 알려지게 된다. 이 때문에 구글에서는 예정보다 빠른 1월 3일에 이 내용을 발표했다.
이 대응 패치 작업은 어마어마한 엠바고가 걸린 상태에서 비밀리에 진행되었는데[* 당연하다. 이게 아무런 대책도 마련되지 않은채로 누설될 경우 그대로 제로 데이 공격의 빌미가 되어 버려 헬게이트 당첨이다.], 리눅스 개발자들이 개발하는 과정에서 커널 핵심부를 건드려야 하기 때문에 할 작업이 많은 데다 그다지 필요 없을 기능들을 추가하기 위해 허겁지겁 일하고, 주고받는 이메일에 CC#s-6로 인텔, 구글, 아마존의 관계자들의 메일 주소가 달려 있고, 코드 주석엔 무언가 검열되어 있고, 인텔 CPU가 위험하다는 플래그가 존재하는 것을 보고 수상한 낌새를 눈치채 작업이 마무리 단계에 이른 시점에 예정보다 일찍 공개되었다.
레딧에서 처음 알려진 버그의 내용은 다음과 같았다. [출처] [출처]
> * 해당 버그는 인텔의 몇 세대에 걸친 버그입니다. 인텔 한정으로, AMD는 영향없는 것으로 보입니다. (다만 현재 커널 패치에서는 AMD를 수정사항에서 제외하는 항목이 머지되지 않은 상태. 즉 현 커널 패치에서는 같이 성능이 떨어질 것으로 예상됨.) > * 해당 버그는 리눅스뿐만 아니라 Windows, macOS 모두에 영향을 줍니다. > * 해당 버그는 엠바고로 인해 아직 전모가 밝혀지지는 않았습니다. > * 해당 버그는 인텔 CPU의 버그로 인해 커널 메모리 정보가 유저 공간으로 유출될 수 있는 결함입니다. > * 해당 버그로 인해 크게 공개되지는 않았지만 데이터 센터/클라우드 업체 등에서는 상당한 물밑작업이 진행되었을 것으로 예상됩니다. > * 해당 버그의 수정으로 인해 발생하는 성능 손실은 각 OS와 기타에 따라 다르지만 대략 5~30% 정도로 알려져 있습니다. > * 해당 버그에 대응하는 리눅스 커널 패치는 이미 릴리즈 되었습니다. > * PCID 기능이 적용된 신형 인텔 CPU에서는 해당 버그의 커널 패치로 인한 성능 저하가 완화되는 것으로 알려져 있습니다. > > * 해당 버그에 대응하는 리눅스 커널 패치를 적용하고 테스트 해 보니…. > 1. 파일시스템 I/O쪽은 성능이 반토막이 납니다. > 1. 컴파일러 벤치마크 중 initial setup 항목에서 15% 정도 성능이 저하됩니다. > 1. 커널 컴파일, 인코딩 등은 큰 영향이 없는 것으로 나타납니다. > 1. SQL 같은 데이터베이스 관련 벤치에서도 15% 정도 성능이 저하됩니다. > 1. 데이터 스트럭처 서버에서 6% 정도 깨집니다. > 1. 게임은 영향이 거의 없습니다.[* 다만 시스템 콜을 많이 사용하는 게임(로딩이 빈번하게 발생하거나 네트워크를 통해 전송되는 정보가 많은 온라인 게임)은 영향을 받을 가능성이 있다. 또한 게임 서버들은 네트워크 및 파일시스템 I/O와 DB 입출력이 매우 빈번하므로 여기서 성능 저하가 있을 수 있다.]
위에 나온 테스트 결과는 이곳에서 확인이 가능하다. [테스트 결과] [테스트 결과]
위 내용 대로라면 현재의 모든 인텔 코어 i 시리즈 및 i 시리즈 기반 제온이 해당 보안 버그에 노출되어 있으며, 이를 운영 체제에서 논리적으로 수정할 경우 최대 30%까지도 성능 하락이 생길 수 있다고 한다.[* 패치 전후의 시스템 콜의 자체의 성능만 테스트한 결과 최대 70% 이상 성능이 떨어졌다는 테스트도 있다. 물론 실제 프로그램에서는 다른 작업을 같이 수행하기 때문에 이 정도로 성능 하락이 일어날 가능성은 없지만, 프로그램의 작동 방식 및 상황에 따라서 매우 큰 폭의 성능 하락이 일어날 가능은 열려 있다.]
구글이나 아마존 등의 대형 IT 업체들 역시 이 문제를 피해가기 어려운 상황이라고 한다.
밝혀진 바로는 1995년부터 발매된 거의 모든 인텔 CPU들이 해당된다.
연구진 공식 Q&A
이하 문답은 이 버그를 발견한 연구진이 게시한 짧은 Q&A의 일부분을 번역한 것이다. 원문은 [[2]]에서 볼 수 있다.
* 제가 이 버그의 영향을 받을까요? * 틀림없이 그렇습니다. * 누군가가 멜트다운이나 스펙터를 써서 저를 공격[* 원문은 익스플로잇(exploit), 컴퓨터 보안 업계에서 사용하는 용어로, 취약점 또는 이를 공격하는 것을 말한다. 단순하게 말하면 해킹.]했는지 알 수 있나요? * 아마도 못 할 겁니다. 이 공격은 기존 방식의 로그 파일에 흔적을 남기지 않습니다. * 제 백신이 이 공격을 감지하거나 방어할 수 있나요? * 이론적으로는 가능하지만, 현실적으로는 어렵습니다. 일반적인 악성코드와 달리 멜트다운과 스펙터는 정상적인 프로그램과 구별하기가 어렵습니다. 다만 악성코드가 발견된 이후에는 코드를 비교함으로써 알려진 공격 방식을 이용하는 악성코드를 탐지할 수 있을 수 있습니다. * 어떤 것이 유출될까요? * 만약 당신의 시스템이 영향을 받는다면, 우리의 개념 실증 코드[* 원문은 our proof-of-concept exploit. 발견한 버그를 활용하여 공격을 가할 수 있음을 보이는 실증 테스트용 코드를 의미한다.]로 당신 컴퓨터의 메모리의 내용을 읽을 수 있습니다. 여기에는 시스템에 저장된 암호와 중요한 데이터가 포함되어 있을 수 있죠. * 멜트다운이나 스펙터가 이미 다른 곳에서 악용되었던 적이 있을까요? * 저희도 모릅니다.[* 이 사람들이 모른다고 욕할 수 없다. 컴퓨터 공학 역사상 전무한 버그이다.]
취약점 상세 정보
||
<#ffffff>
멜트다운
|| width=100% || || 멜트다운 데모. 메모리에 입력되는 비밀번호가 CPU에 정보 입력 즉시 노출되고 있다.[* 해당 영상이 나오기 전엔 성능저하 때문에 업데이트를 고민하는 사람이 많았지만 시연 영상이 뜨자마자 대부분 태세전환했을 정도로 심각한 상황임을 보여주고 있다.][*원본 [[3]]] ||
현재까지 나온 모든 보안 정책들을 무력화시키고 운영 체제 심장부의 메모리를 마음대로 읽을 수 있게 하는 초대형 하드웨어 취약점. 멜트다운 취약점은 하드웨어 구조적 결함이라 업데이트같은 소프트웨어적 미봉책으로는 사실상 완전히 막을 수 없다.
~~[[4]]~~ [일부 요약](본문 및 CBear 베플.)
* 주의: 인텔만 취약하다고 밝혀진 시점에서 쓰여진 터라 인텔 위주로만 분석해놨다. 그러나 이후 ARM 기반 프로세서를 쓰는 애플 기기들과 닌텐도 스위치[* 이는 애플의 모바일 기기에 들어간 칩셋들이 ARM의 명령어 셋을 취득해 변형한 후 쓰기 때문으로 보인다. 특히 CPU 보안 버그 3a에 포함되는 ARM Cortex-A72, Cortex-A57, Cortex-A15는 애플도 쓰고 있는 ARMv8-A에서 파생되어 나온 CPU들. 닌텐도 스위치의 경우도 테그라 X1의 빅 코어가 코어텍스 A57 기반이라 영향을 받는 것으로 추정.], [일부 POWER CPU 등도 취약한 것으로 밝혀졌다.]
멜트다운을 설명하기 위해서 CPU의 아키텍처와 마이크로아키텍처 두 가지에서 최소한의 정보를 서술하겠다. 참고로 CPU의 아키텍처와 마이크로아키텍처의 구분은 사용자(혹은 운영체제)가 기대하는 CPU의 동작 방식이 전자고 이를 실현하기 위한 구체적인 전략이 후자라고 보면 된다. CPU 마이크로아키텍처와 아키텍처에 대한 설명은 CPU/구조와 원리 문서 참고.
커널 값을 읽어내는 프로그램
위에 서술되어있듯 이 프로그램은 컴퓨터공학, 그중에서도 특히 컴퓨터 구조에 대한 전공 지식을 이용한다. 컴퓨터공학과에서도 학부 저학년용 아키텍처 수업은 이 부분을 다루지 않고 학부 고학년 수업에서 슈퍼스칼라, 비순차적 명령어 처리, 캐시 등의 개념을 본격적으로 다루는 경우가 많기 때문에 전공자라 해도 이해하려면 꽤 고민을 해야 하니 읽으면서 좌절할 필요가 없다.
따라서 최소한의 내용만을 설명하는 부분과 전공자를 위해 전문용어와 약간의 기법이 추가된 설명 두 가지를 첨부한다.
일반인에게 중요한 것은 보안패치 잘 하고 가능하면 AMD 계열의 CPU로 시스템을 변경하는 것이다. 5. 취약점에 대한 대응 문단과 6. 사용자가 할 수 있는 대처법을 참고하자.
비전공자를 위한 설명
해외 순방 중인 대통령을 암살하려는 범죄조직이 있다고 하자. 이 조직은 대통령이 어느 호텔의 A동에 묵는다는 것까지는 알아냈다. 그러나, 몇 호실에 있는지는 알아내지 못했다. 여기서는 A동 503호라고 하자. 대통령 관련 정보는 1급 기밀사항이므로 호텔 프론트에는 "A동 관련 질문은 일절 답변하지 말라"는 엄명이 내려와 있다. 따라서 "대통령이 A동 몇 호실에 묵고 있나요?" 라고 물어봐도 당연히 "대답해 드릴 수 없습니다." 라는 답변만 돌아올 뿐이다. 여기서 조직원은 잔머리를 굴려 프론트 직원의 노하우를 역이용하기로 한다. 프론트 직원은 다음과 같이 일을 처리한다고 알려져 있다.
>1. 특정 호실에 대한 문의가 자주 들어오면 직원은 그 방을 시스템에서 자꾸 검색하는 수고를 덜기 위해 해당 방의 정보를 메모지에 적어 놓는다. >2. 메모지에 적어놓은 방의 정보는 검색하지 않고 메모지를 참고해 다른 방에 비해 훨씬 빠르게 대답해준다. >3. 메모지에 뭐라고 적혀있는지 직접 묻는 질문에는 대답하지 않는다.
작전 1단계. 우선 질문을 다음과 같이 바꾼다.
> "B동 호텔방 중 A동의 대통령이 묵는 호실과 같은 호실이 몇 호실인가요?"
A동 관련 질문이 들어갔기 때문에 직원은 여전히 "대답해 드릴 수 없습니다." 라고만 대답할 뿐이다. 그런데 상기했듯 프론트 직원은 특정 방에 대한 문의가 많이 들어온다 싶으면 호텔 시스템을 계속 뒤져보는 귀차니즘을 덜기 위해 __해당 방의 정보를 메모지에 적어 놓는 습관__이 있다. 이제 저 질문을 계속 반복해서 직원의 귀차니즘을 자극해 보자. 그러면 직원은 계속 "대답해 드릴 수 없습니다."라고 대답은 하면서도 메모지에다가는 문제의 "B동 호텔방 중 A동의 대통령이 묵는 호실과 같은 호실", 즉 B동 503호의 정보를 적어놓을 것이다.
직원의 귀차니즘을 충분히 자극했다 싶으면 작전 2단계로 간다. 작전의 목표는 메모지에 적힌 호실이 어디인지 알아내는 것. 다만 상기했듯 메모지의 내용을 직접 묻는 질문에는 여전히 묵비권을 행사한다. 하지만 간접적으로 알아낼 방법은 있다. 바로 "2. 메모지에 적어놓은 방의 정보는 검색하지 않고 메모지를 참고해 다른 방에 비해 훨씬 빠르게 대답해준다."를 이용하는 것. 이를 위해 "A동"이라는 말은 싹 빼고 B동에 있는 모든 방에 대해 직원에게 순서대로가 아닌, 마구잡이로 캐묻는다. 방의 정보를 순서대로가 아닌 마구잡이로 캐묻는 이유는, 순서대로 물어보면 규칙을 예측한 프론트 직원이 물어보는 방 정보의 뒷방 정보를 메모지에 미리미리 적어놓아서 빨리 대답해버리기 때문에 귀차니즘을 자극한 게 무용지물이 될 수 있기 때문이다. 즉,
> "B동 1209호 비어 있나요?" > "B동 310호 비어 있나요?" > "B동 716호 비어 있나요?" > ...
이렇게 마구잡이로 물어보면, 문제의 "B동 호텔방 중 A동의 대통령이 묵는 호실과 같은 호실", 프론트 직원이 이미 메모지에 적어 놓아서, 호텔 시스템을 검색할 필요 없이 뜸을 들이지 않고 바로 대답해주는 호실을 찾는 것이다. 결국 프론트 직원이 메모지에 써놓은 호실이 B동 503호임을 알 수 있게 되는 것이다. A동 관련 질문은 일절 답변하지 말라는 엄명이 내려와 있지만, B동에 대해서는 특별한 지침이 내려오지 않았기 때문에 직원은 모두 순순히 대답을 해 줄 것이다.
해당 방이 비어있는지 아닌지 물어볼 때마다 아무것도 모르는 프론트 직원은 호텔 시스템을 검색하기 위해 "잠시만요.." 하며 뜸을 들일 것이다. 이로부터 조직원은 프론트 직원이 메모지에 적은 방 = 프론트 직원이 뜸을 들이지 않고 바로 대답해준 방이 B동 503호임을 알 수 있게 되고, 여기서 B동을 A동으로만 바꾸면 거기에 대통령이 있다는 것을 알 수 있다. 일을 효율적으로 하기 위한 프론트 직원의 노하우가 여기서는 오히려 기밀정보를 유출시켜 대통령을 위험에 빠뜨리는 결정적인 계기로 작용한 것이다.
전공자를 위한 간단한 설명
설명을 위해 CPU의 구조에 대한 최소한의 지식이 필요하다. 첫째, CPU 안에는 '레지스터'라는 것이 있다. CPU는 일을 할 때 임시로 숫자를 여기에 적어둔다. 둘째, RAM이 있다. 각종 프로그램들은 여기에 자신이 필요한 정보를 적어둔다. 셋째, 캐시가 있다. 캐시는 RAM에 비해서는 매우 빠르게 정보를 넣었다 뺐다 할 수 있다.
RAM에는 여러 칸이 있으며 프로그램은 각 칸의 번호를 바탕으로 RAM에 숫자를 적어넣거나 읽어온다. 호텔을 생각하면 된다. 1번 방에 철수가, 2번 방에 영이가, 3번 방에 민수가 있다. 2번 방에 누가 있는지 알고 싶으면 호텔 데스크에 '2번 방, 누구?' 이렇게 질문하면 데스크는 '영이'라고 답할 것이다. 3번방의 민수를 퇴실시키고 싶다면 '3번 방, 퇴실' 이라고 데스크에 명령하면 된다. 대략 이런 방식으로 프로그램은 RAM에다가 숫자를 저장하거나 읽어내기 위해 CPU에 명령을 내린다. 다만, 이 때 RAM은 너무 느리기에 중간에 캐시라는 임시저장소를 둔다. 캐시의 세부사항에 대해서는 여기에서 서술하지 않는다.
당신이 키보드로 무엇을 입력했는지 훔쳐내려는 해커가 있다고 생각해보자. 키보드로 무엇을 입력했는지 알아내면 은행 거래 비밀번호 등 중요한 정보를 탈취해낼 수 있다. 해커의 목적이 키보드 입력값의 탈취라는 전제 하에 다음의 사항을 생각해 보자.
컴퓨터는 모든 것을 숫자로 처리한다. 가령 ASCII코드를 전제할 때 컴퓨터는 'a'라는 문자를 97로 이해하고 'b'라는 문자를 98로 이해한다. 우리가 키보드로 'a'를 칠 때, 컴퓨터는 메모리의 100번째 방에 숫자 97을 적어넣는다고 치자. 원칙적으로는 OS의 핵심부분인 커널 이외에는 메모리의 100번 방에 무슨 내용이 들어가 있는지 아무도 알 수 없다.[* 커널은 윈도우/맥OS/리눅스 등 운영체제의 핵심 부분을 이룬다. 그 자체로는 소프트웨어이지만, 물리적인 하드웨어와 다른 소프트웨어 사이의 연결을 담당한다. 하드웨어와 거의 직접적으로 연결되는 부분이기에 CPU나 메모리 등 하드웨어에서도 커널 소프트웨어의 동작을 돕기 위한 장치가 되어있다.] 만약 해커가 100번째 방의 내용을 노리고자 '메모리의 100번째 방을 읽어서 나한테 보내라'라는 명령을 내리면, CPU는 권한 오류로 명령을 거부하게 된다. CPU가 아무한테나 100번째 방의 내용을 보내준다는 것이 가능하다면 비밀번호 등 우리가 키보드로 친 내용들이 유출되기 때문이다.
100번째 방의 내용을 읽어내기 위해 해커는 두 개의 명령을 CPU에게 연속해서 전달한다. 첫 번째는 '메모리의 100번 방에 있는 내용을 레지스터 al로 복사해라' 이며 두 번째는 '1000+al을 계산한 다음 RAM에서 그 방에 있는 숫자를 가져다 줘'이다. 즉 100번 방의 내용 → al → 1000+al을 통해 해커는 100번 방의 내용을 알아내려고 하는 것이다. 만약 1000+al이 1097이라면, 'a'가 97인 점을 이용하여 해커는 키보드에서 'a'가 입력되었다는 것을 알아낼 수 있다.1000+al이 1098이라면 해커는 'b'가 입력되었다는 것을 알 수 있다.
즉, 해커가 시킨 일을 하기 위해 CPU는 다음의 일을 해야 한다. 1. 100번 방에서 숫자를 꺼낸다. 2. 100번 방에서 꺼낸 숫자를 레지스터 al에 임시로 저장한다. 3. al에 저장된 숫자와 1000을 더한다. (여기에서는 1097로 가정하자) 4. 3에서 더한 결과에 해당하는 RAM의 숫자를 꺼낸다. (즉, 1097번 방의 자료를 꺼낸다.) 5. 꺼낸 숫자를 해커에게 전달한다.
상기에 서술한대로, 이 일련의 과정들은 권한 오류를 일으킨다.
문제는 CPU의 파이프라인 구조에 있다. 해커가 100번방의 숫자를 꺼내라고 했을 때, CPU는 권한 여부에 상관없이 일단 100번 방의 숫자를 꺼낸다. 그리고 RAM의 1097번 방의 숫자도 꺼낸다. 즉, 실제로 CPU는 해커가 시킨 일을 다 한다. 단지 보여주지 않을 뿐이다. 예전까지는 해커한테 보여주지만 않으면 괜찮다고 생각했기 때문에 이런 방식이 사용되었다.[* 여기에 명령어 디자인의 철학이 반영되있음을 엿볼수 있다. 정상적이라면 1번 명령을 실행하려면 <1번명령 접수> -> <1번 명령 권한 체크> -> <체크됨-명령 실행|체크 안됨-명령 중지> 라는 순서로 되어야 한다. 하지만 이런식으로 모든 명령에 대하여 권한 체크를 하게 된다면 순차적으로 진행해야하고 그렇게 되면 시간이 늘어지게 된다. 그래서 생각해 낸게 지금의 보안 결점의 핵심이다. <1번명령을 접수> -> <1번명령 실행과 동시에 권한 체크> -> <체크됨-숫자를 보여줌|체크 안됨-명령 중지> 라는 순서로 되어 읽어 보여줄때 벌써 캐시에(레지스터와 동일하고 읽기/쓰기 가 가장 빠르다) 불러와 있는 값을 주면 되기에 속도가 빨라진다.] 'CPU가 일을 다 하고 보여주지만 않으니, CPU가 일한 흔적을 찾아 100번 방의 숫자를 알아내자'라는 것이 멜트다운 버그의 핵심 아이디어이다.
해커는 앞서 간단히 언급한 캐시를 이용한다(캐시는 램보다 속도가 훨씬 빠른 메모리이다). CPU가 RAM의 1097번 방에 있는 정보를 꺼낼 때, 1097번 방의 정보는 자동으로 캐시에 기록된다. RAM에 있는 정보를 캐시로 베껴 써 두면 나중에 다시 볼 때 이를 빠르게 볼 수 있기 때문이다.[* 자세한 것은 메모리 계층 구조 참조] CPU는 해커에게 RAM에서 일껏 1097번 방의 자료를 꺼내오고는 해커에게 보여주지는 않는다. 하지만 어쨌든 1097번 방의 자료를 꺼내왔기에 1097번 방의 정보는 캐시에 들어가 있다. CPU가 RAM을 읽으면 무조건 이 정보는 캐시에 기록되기 때문이다.
이제 해커는 RAM의 1000번 방부터 하나씩 방을 검색하기 시작한다. 1000번 이후의 모든 방들은 캐시에 없기 때문에, 램에서 읽어와야 하므로 읽는 데 시간이 꽤 오래 걸린다. 하지만 1097번 방은 캐시에 있기 때문에, 읽는 데 시간이 적게 걸린다. 해커는 RAM의 1000번 방 이후의 방을 읽을 때마다 읽는 데 걸린 시간을 측정한다. 1097번 방을 읽을 때 시간이 적게 걸리는 것을 잡아내면, 해커는 CPU가 나한테 보여주지는 않았지만, 실제로는 1097번 방을 읽었다는 것을 알게 된다. 이를 근거로 al에 원래는 97이 들어가야 했다는 것을 알 수 있고 우리가 키보드로 'a'를 쳤다는 것을 알 수 있다.
전공자를 위한 보다 더 기술적인 설명
기술적으로 완벽한 설명을 하기 위해서는 시스템의 비트 상황이나 캐시구조 등 하드웨어의 세부사항까지 이해해야 한다. 진짜 작정하고 파고들면 한도끝도 없는 아스트랄한 내용이 쏟아지므로 여기에서는 대략적인 개요만을 설명한다. 캐시와 타입캐스팅을 어떻게 활용하는지 확인하는 용도로 사용하면 적절하며 그 이상으로 정확하지는 않다.[* 보다 좋은 설명을 하고싶다면 가급적 Variant 3 또는 3a 코드를 직접 읽은 사람이 '기술적으로 완벽한 설명' 문단을 새로 작성할 것을 권한다. 아울러 3.1.1~3.1.3 문단까지의 내용은 여러 차례 토론을 거쳐 합의된 것이기에 수정을 원할 시 토론을 거치는 것이 좋다.] 이 설명은 OS와 메모리 구조, CPU 파이프라인에 대한 전공지식이 있다는 것을 전제로 한다.
공격 프로그램은 커널의 특정 메모리 주소를 읽기 위해 다음의 변수 및 배열을 설정한다.
1. ka: 값을 읽어올 커널의 메모리 주소. 2. ua1: L1 캐시 크기 만큼의 배열 3. ua2: 256 크기 만큼의 배열. [* 실제로는 캐시가 RAM에서 정보를 한 번에 가져오는 단위인 캐시라인을 고려해야 한다. 여기에서는 설명을 위해 단순화 시켰다.]
코드의 실행순서는 다음과 같다. A. ka에 원하는 주소를 세팅한다. B. ua1의 모든 값을 읽는다. C. ka의 값을 읽어서 레지스터 al에 저장한다. D. ua2[al]의 값을 읽는다. E. 아무 것도 하지 않는 명령어를 적당히 깔아둔다. F. ua2에서 캐시로 값이 들어온 주소를 알아낸다.
위 코드의 실행 순서를 바탕으로 자세한 동작 원리는 다음과 같다.
첫째. B에서 ua1의 값을 모두 읽었기에, L1 캐시는 ua1의 정보로 가득 차 있다. 따라서 이 시점에서 ua2의 정보는 캐시에 없다는 것이 보장된다. 둘째. C는 항상 실행이 취소된다. 사용자 프로세스가 커널 정보를 읽는 것이기 때문에 보호비트가 발동된다. 셋째. C가 실행이 취소되기 전, C, D는 파이프라인의 execute state를 지난다. 즉, CPU는 ua2[al]의 값을 읽는다. 단지 commit 하지 않을 뿐이다. [* C가 실행되지 않았는데 D가 실행될 수 있는 이유는 파이프라인 구조에서 성능향상을 위해 실행이 완료되지 않은 명령어의 정보를 다른 명령어에게 전달할 수 있기 때문이다.] 넷째. 컴퓨터에서 array에 접근할 때에는 보통 간접적인 방식으로 접근한다. C언어에서 tmp_arr[10]이라고 적는 경우를 생각해 보자. 실제로는 tmp_arr이 가리키는 주소에서 10을 더하는 방식으로 주소를 계산한다. ua2[al]을 읽을 때에도 마찬가지로 계산한다. 다섯째. D는 execute state를 지났으므로, CPU는 실제로 ua2[al]을 읽는다. 따라서 이 값이 ua2 배열 중 유일하게 캐시에 올라와 있다. al이 97 즉, 'a'라면 ua2[97]만 캐시에 올라와 있고 나머지는 캐시에 없다. 여섯째. F단계에서 해커는 ua2[0]~ua2[255]까지를 랜덤한 순서로 전부 읽어본다. 읽을 때마다 읽기 시간을 측정한다. 다른 모든 값은 캐시에 없으니 읽는 데 시간이 걸리지만, ua2[97]은 캐시에 올라와 있으니 읽기 시간이 빠르다. 이를 근거로 ka값이 가리키는 주소에 97이 들어있다는 것을 알 수 있다. [* CPU클락 카운터 등 정밀한 시계를 사용한다.][* 읽기는 무작위로 해야한다. 순서대로 읽을 경우 CPU에서 이를 예측하고 ua2의 일부 내용을 캐시에 미리 올릴 수 있다.] 일곱째. E에서 아무 것도 하지 않는 명령어를 적당히 깔아두는 이유는 F가 실행취소되거나 재시도 되는 것을 막기 위한 의도적인 파이프라인 버블이다.
AMD CPU에 멜트다운 취약점이 존재하지 않는 이유
이 사달이 난 이유는 D단계가 잘못된 것을 꽤 일찍 알았는데도 실행 취소가 시작된 시점이 완료(Commit) 단계여서 이미 뒤의 명령어들이 실행되어 버렸기 때문이다. AMD는 D단계와 같은 보호 비트 위반을 발견하는 대로 실행 취소를 시작했거나, 보호 비트 위반으로 읽어낸 eax와 같은 값을 읽는 명령어들은 송출(Issue) 단계를 지나지 못하게 막았을 것이다.
다만 AMD 측이 해당 보안 이슈를 알아서 막았다기 보단, 인텔과 다른 전략으로 마이크로아키텍처를 설계하여 잡아서 우연히 피했을 가능성도 있다. 일단 CPU 아키텍트 인재 풀이 그리 크지도 않고 회사도 생각보다 자주 옮겨다닌다.[* 당장 AMD의 구세주라고 칭송받은 짐 켈러만 해도 AMD와 인텔 양쪽에 몸담았던 경력이 있다.] 그러므로 불과 몇 년 전까지는 아무도 이 문제를 몰랐을 가능성이 매우 높다. 인텔의 전(前) CPU 아키텍트 프랑수아 피에노엘은 "이번 버그는 컴퓨터 과학의 새로운 발견이며, 발견되기 전에 몰랐다고 해서 과학자들을 비난할 수 없다."라고 트위터에 [[5]]을 올렸다.[* 15년간 아무도 알아차리지 못하고 아무도 이를 활용하지 못한것을 보면 정말 새로운 발견이라고 하지 않을수가 없다. 만약 그냥 흔하게 생기는 치명적 버그 1이었다면 그 전에 정부기관이나 다른 업체에서 금방 발견하지 이렇게까지 질질 끌수가 없다.]
왜 두 가지 방식으로 갈렸는지는 다음과 같이 추측해 볼 수 있다. 먼저 AMD의 빠른 예외 처리 방식을 쓰면, 파이프라인 안에서 적절한 취소 시그널을 보내는 로직이 복잡해지겠지만 쓸데없는 명령어에 허비하는 에너지를 줄일 수가 있다. 반면에 인텔 방식은 쓸데없는 명령어에 허비하는 에너지가 늘겠지만 예외 처리의 로직이 단순화되어 평상시의 에너지 효율이 증가하고 그 밖의 TSX와 같은 더 복잡한 기술의 도입이 쉬워진다. 즉, 보안 취약점만 빼고 보면 딱히 우위에 있는 게 아니라는 것. 하지만 보안은 컴퓨터에게 있어서 생명과 같다. 아무리 성능이 효율적으로 나온다고 해도 보안이 막장이면 소용 없다.
차기 인텔 하드웨어의 해결책 예상
AMD와 마찬가지로 보호 비트 위반과 같은 예외(exception)를 처리하기 시작하는 시기를 완료(Commit) 단계가 아닌 실행(Execute) 단계 즈음으로 대폭 앞당길 가능성이 높다.
추측 실행(Speculative execution)을 제거하면 어떻겠냐고 하는 사람도 있는데, 사실상 불가능한 방법이다. 이유는 다음과 같다.
1. 추측 실행(Speculative execution) 없이 중단(interrupt)을 지원하려면 가끔 일어나는 중단(interrupt) 처리를 위해 끔찍한 성능 감소를 감수해야 한다. 중단(interrupt)은 외부 장치의 핸들링이나 내부 명령어의 예외(exception) 처리를 운영체제가 미리 등록한 별도의 코드로 실행할 수 있게 하는 필수적인 기능이다. 문제는 중단(interrupt) 발생이 대부분 명령어에서 일어날 수 있다는 것이다. 결과적으로 대부분 명령어는 잠재적인 분기 명령어가 되며, 따라서 추측 실행(Speculative execution) 없이는 명령어 대다수가 실행(Execute) 단계가 완수해서 중단(interrupt) 발생 여부를 확인하고 나서야 다음에 호출(Fetch)할 명령어를 알려줄 수 있게 된다. 이는 결코 받아들일 수 없는 사태이므로, 중단(interrupt)은 매우 드물게 일어나는 점에 착안해 중단(interrupt)은 항상 일어나지 않는다고 예측해도 거진 다 맞게 되고 성능도 대폭 향상된다. 한 마디로 잘 일어나지도 않을 일을 확인한다고 전 공장이 매번 올스톱하는 것과 같다. 그럴 바에는 그냥 공장을 계속 돌리다가 문제 생긴 제품을 폐기하는 것이 이득이다. 1. 분기 예측(branch prediction)은 안 쓰면 손해가 크다. * 분기 예측은 분기(branch)명령어가 "파이프라인이 호출(Fetch) 단계에서 자꾸 쉬게 만드는 문제"를 해결하기 위해 도입된 것이다. 파이프라인을 안 쓰는 CPU는 없다고 봐도 된다.[* 파이프라인을 안 쓰면 지독한 성능저하를 경험한다. 여담이지만 요새도 산업용으로 근근히 POS에서 보이는 1~3세대 아톰 CPU들과 잔존하는 486호환 CPU들은 분기예측이 없다.] * 각종 추측 실행(Speculative execution) 기능의 제거가 빈번한 저전력 CPU도, 프로그램이 대부분의 시간을 반복문에서 보내는 특성상 분기 예측(branch prediction)이 맞을 확률은 매우 높은 편이다. 에너지적인 관점에서 아주 간단한 분기 예측(branch prediction)이라도 하면 전력을 약간 더 써서 성능을 대폭 올리니 결과적으로 에너지 효율적이게 된다. * 비순차적 명령어 처리(OoOE)를 버린 저전력 CPU는 명령어의 실행 취소가 매우 간단하여, 분기 예측(branch prediction) 실패에 대한 댓가마저도 훨씬 적다. 1. 비순차적 명령어 처리(OoOE)의 경우 현재도 저전력 CPU에서는 안 쓰기도 하므로 분기 예측(branch prediction)과 달리 버린다는 옵션이 있긴 하지만, 고성능 CPU 시장에서는 비순차적 명령어 처리(OoOE)로 인한 성능 향상이 상당하다. 저걸 걷어내면 아톰이나 J 시리즈 계열 정도의 성능밖엔 안 나올 가능성이 높다. 물론 저런 제품들은 15W 이하로 동작하므로 실제 데스크톱용으로 90W쯤으로 TDP를 올려 설계하면 성능 향상이 되겠지만, 그렇다 해도 넷버스트 아키텍쳐 시절 수준의 전성비가 다시 강림할 가능성이 크다. 물론 문제 해결이 생각보다 어려울 경우에는 보안을 포기하느니 전성비를 포기하는게 훨씬 나으므로, 그렇게 되면 과거 AMD불도저나 넷버스트 시절마냥 펜티엄과 셀러론이 95W TDP를 갖고 i 시리즈는 135W~225W의 아름다운 소모전력을 자랑하게 될 것이다. 참고로 AMD는 불도저,비쉐라 시절까지도 클럭당 성능비가 후달리는걸 억지로 클럭빨로 해결했기 때문에 왠만한 시퓨들이 95~135W였으며, 터보클럭 5Ghz짜리 225W CPU가 있었다. 결국에 OoOE를 버리기로 한다면 아마도 저렇게 될 듯(...)
운영체제를 통한 임시방편
CPU 아키텍처 설명 중 맨 마지막에 최신의 커널에는 재미있는 최적화가 있는데, 유저 프로세스의 가상 메모리의 특정 주소는 커널 데이터를 담고 있다는 것이다.를 멜트다운 버그를 해결하기 위해 없애버렸다. 이는 임시방편이다. 즉 보호 비트에 의존해서 유저와 커널의 가상 메모리 공간을 합치던 최적화를 포기하고, 다시 두 메모리 공간을 분리해 버린 것이다. 따라서 유저 프로세스에서 커널 기능을 사용할 때마다 페이지 테이블이 교체되는 작업이 추가로 필요해진다. 결과적으로 구체적인 정도의 차이는 있을지언정, 파일을 읽고 쓰거나 네트워크 송수신을 하는 소위 입력/출력(Input/Output, I/O)을 포함해 커널의 메모리 권한으로만 가능한 작업들의 성능이 하락할 수밖에 없다.
심각성
커널 권한을 가지고 있지 않은 프로그램에서 커널 메모리를 읽을 수 있다는 것만으로도 이 문제점의 심각성이 얼마나 높은지 잘 알 수 있다. 보안 문제가 생길 경우 영화에서나 보던 온갖 사건사고가 발생하고, 재해 수준의 대형 사고가 이어지는 것도 무리는 아니다.
다만 멜트다운 취약점 자체만으로는 커널 메모리의 읽기만 가능하고 쓰기는 불가능하므로, 직접 시스템에 파괴적인 행동을 하거나 랜섬웨어 등 악성코드를 심는 것은 불가능하다. 이 취약점을 이용하기 위해서는 어떤 식으로든 다른 방법을 통해 먼저 시스템에서 공격하는 코드를 실행하도록 해야 한다. 그러니까, 알려진 바 대로 갑자기 전세계 대부분 컴퓨터의 보안이 무력화 되고 그러는 것은 아니라는 것.
하지만 그렇다 해도 이 보안 문제점은 평소엔 기를 쓰고 보려고 해도 볼 수 없었던 커널 메모리의 내용을 누워서 떡먹듯 들여다 볼 수 있는 치명적인 결함이 명백하며[* 현대의 보안 프로토콜은 비대칭키 기반 암호화 알고리즘을 사용하는데 이 암호화 알고리즘이 작동할 때에는 CPU에 특징적인 어떤 '흔적'이 발생한다.이 흔적을 추적하여 멜트다운 공격을 시도하면 암호화에 사용되는 개인키를 유출할 수 있고 개인키가 유출된 시스템은 그 이후의 모든 통신을 수신, 변조, 사칭할 수 있다.], 읽기 전용의 한계도 물리적 보안을 뚫고 별도의 해킹 프로그램들과 연계하면 당연히 위협적이라는 것은 주지의 사실임이 분명하다.
또다른 문제로는 멜트다운 취약점을 이용할 때 특별한 징조를 보이거나 흔적을 남기지 않는다는 것이다. 일반적으로 보안 취약성을 악용하는 코드는 이용하는 명령 자체가 시스템에 기록이 남기 쉬운 명령을 이용하거나 권한을 얻는 과정 등 기존에 시스템에서 이용하던 동작을 이용하던 과정에서 취약점을 이용하고 이 과정에서 흔적을 남기거나, 또는 특정 보안 취약성에 맞게 작동하는 과정에서 코드 및 명령어 자체가 특정한 패턴을 보이는 경우가 많다. 하지만 멜트다운 취약점은 훨씬 범용적인 명령어 및 동작을 통해서 이용이 가능하다. 따라서 작동의 감지도 어려울 뿐 아니라 해당 코드가 공격 코드인지 판단하는 것도 어렵다.
하드웨어적 취약성이기 때문에 OS 환경 제약을 받지 않는 다는 것 역시 문제다. 보통 맥OS나 리눅스에서는 대부분 사용자 권한만 가지고도 대부분의 악성코드를 차단할 수 있었지만 위에서 보았다 시피 자바스크립트 가지고도 동작이 가능했기 때문.
무엇보다도 절망적인 것은 멜트다운 취약점의 원인이 십수년간 변하지 않은 (특히 인텔) CPU 하드웨어 구조적 결함이라 업데이트같은 소프트웨어적 해결책으로 완전한 해결을 보장할 수 없는 것도 문제다. 이는 그 어떤 소프트웨어이든 하드웨어 위에서 구동되는 이상 어쩔 수 없는 한계다. 실제로 소프트웨어적인 패치는 모든 멜트다운 공격을 막을 수 없다는 전문가 [[6]]이 있다. 즉 실질적으로 멜트다운 취약점을 이용하지 못할 정도로 업데이트가 가능할 수도 있지만, 그렇게 되지 않을 가능성도 있는 것이다. 설령 공격의 난이도가 높아도 취약점 공격의 대가가 크다면 이용의 어려움이고 뭐고 없이 달라들 수도 있는 것이고. 이 문서에 서술된 '멜트다운' 취약점에 한정한다면 OS의 최적화 과정을 포기해서 커널과 유저의 페이지 테이블을 분리하는 정도로도 충분한 방어가 가능하지만, 이건 CPU 자체의 한계를 해결한 것이 아니라 그 약점이 악용될 가능성 중 하나를 막은(혹은 어렵게 한) 것에 불과하다. 즉, 구조적으로 하드웨어 차원에서 해당 문제의 근본적인 해결이 되지 않는 한 해당 취약점을 악용할 가능성은 남아 있을 수 있다. 그리고 이런 경로 모두를 실제 악용 전에 미리 발견하는 것이나, 설령 발견하더라도 소프트웨어적인 해결책을 찾아내는 것은 현실적으로 거의 불가능하다.
인텔 CPU 사용시 설령 성능저하가 있더라도 OS가 이 문제를 틀어막아주지 않으면 안되는 이유다. 따라서 기존의 보안 문제하고는 차원이 다르게 범용성 높은 취약점이다. 다만 커널의 어느 값이나 쉽게 읽을 수 있을 뿐 어디를 읽어야 하는지 알아내는 과정에는 상당한 연구가 필요하고, 그렇게 기를 써서 뚫어봤자 캐낼만한 값진 정보를 가진게 아니기에 당장 개인 사용자를 타겟 삼아서 취약점을 악용하는 사례는 나오지 않을 가능성이 높다. 그러나 기업이나 공공기관 같은 곳은 일단 뚫기만 한다면 매우 값진 기밀 정보를 담고있을 것이 100%이기에 무슨 짓을 해서라도 접근하려는 시도가 많아질 수 있으며 무엇보다 타인과 공동으로 사용하는 클라우드 환경 역시 매우 취약해지게 된다. 일단 구글에서는 구글 클라우드의 가상화 시스템의 특성상 멜트다운/스펙터 취약점을 이용하는 것이 불가능하다고 발표했지만 다른 곳도 안전하다는 보장은 없다.
만약 패치로 보안 문제를 완화하는데 실패할 경우, 결국 CPU를 완전히 바꿔야하는데, 인텔의 경우에는 2011년부터 생산되는 거의 모든 CPU가 확실히 해당되며, 잠재적으로는 1995년부터 해당되는 거의 모든 인텔 CPU에 취약 가능성이 있으므로, 현재로선 다른 인텔 CPU로 교체라는 선택지는 사실상 존재하지 않는다. 이렇게 되면 결국 인텔의 CPU를 AMD의 ZEN 아키텍처 기반 CPU로 옮기는 것 외엔 방법이 없다. 이로 인해 들어갈 각종 비용은 계산이 어마어마할 것이라는 것은 조금만 생각해 봐도 알 수 있다.[* 현재로썬 교체자체가 불가능하다. 거의 모든 인텔 CPU에 문제가 있는데 미국 CERT/CC에선 처음엔 하드웨어 교체가 필요하다고 했지만 다음날에 철회하고 소프트웨어 패치로 버티는 방식으로 바꿨는데 여기에는 현재 나와있는 대부분의 인텔 CPU가 영향을 받는 것도 원인이 있는 것으로 보인다. 스펙터 취약점까지 고려하면 자유로운 CPU가 없는 것도 문제고.]
스펙터
한편 스펙터(또는 스펙터 익스플로잇)은 멜트다운 버그와 비슷하게 추측 실행(speculative execution)으로 인해 일어나기는 하지만, 조금 덜 심각하다.[* 하지만 그렇다 해도 심각한 건 마찬가지이다. 가장 원초적이면서 가장 기본이 되는 가장 깊은 곳에서, 절대로 남이 봐서는 안되는 정보가 해킹될 수 있기 때문. 또한 후술하다시피 스펙터는 구현하기가 어렵지만 막는 것도 그만큼 어렵다.] 스펙터는 추측 실행을 할 때 다른 곳의 코드 실행[* 함수 호출 뿐 아니라 더 일반적으로 {{{jmp}}}와 같은 점프를 뜻한다.](분기표적 주입 (branch target injection) 의 경우)이나 조건문(경계검사 우회 (bounds check bypass) 의 경우)을 실행한 뒤 잘못된 경우에 취소시키는데, 이때 비슷한 부작용이 발생하는 점을 악용하여 다른 프로그램의 메모리를 읽어들이는 것이다.
다만 메모리를 훔쳐볼 수만 있고 메모리에 기록할 수는 없으므로 그 자체만으로 직접 시스템에 파괴적인 행동을 하거나 랜섬웨어 등 악성코드를 심는 것은 불가능하다. 또한 커널 영역 메모리에 접근 가능한 것은 아니므로 상대적으로 멜트다운보다는 시스템에 끼치는 영향은 좀 더 적을 것으로 보인다. 하지만 다른 프로세스의 메모리에 올라온 모든 정보를 해커가 읽을 수 있는 이상, 직접 각종 개인정보를 유출하여 이메일, 검색포털, 스팀, 배틀넷 등의 계정을 탈취하거나, 최악의 경우 은행 공인인증서 뱅킹 전자서명까지 죄다 털리고 현금이 인출되는 상황이 벌어지거나 하는 일이 벌어질 가능성은 있다. 게다가 이러한 일련의 공격을 막기 위해 데이터를 암호화하는 것도, 그 암호의 복호화 키가 메모리에 있는 한 키 역시 같이 유출될테니 근본적인 해결책이 되지 않으며, 상술했듯이 공격을 수행하는 것 자체를 막는 것도 악성코드의 소행인지를 판단하기 어렵기 때문에 어려운 것도 문제다.
스펙터 버그의 경우 유저들의 프로그램간 메모리 스니핑이 일어나는 거긴 하지만, 기본적으로 대상 프로그램에서 문제가 존재하는 코드의 추측 실행이 되어야 하기 때문에, 실제 버그를 이용해 공격하려면 공격하려는 대상 프로그램을 세세하게 분석해야 되고, 프로그램이 돌아가는 CPU 아키텍쳐나 운영 체제에 대해서도 자세히 알아야 되고, 실제로는 취약점을 공격하긴 매우 어렵다. 단, 어느 코드에서나 문제가 존재할 가능성이 있기 때문에, 문제를 발견해 막기도 힘들다(그래서 이름이 유령, Spectre이다). 예를 들어 프로젝트 제로측에서는 리눅스 커널 상에서 실행되는 패킷 필터 JIT 컴파일러를 이용해 문제가 되는 코드를 커널 컨텍스트상에서 만들어 실행시켰다. 그래서 스펙터의 경우 긴급 보안 패치는 난이도를 훨씬 더 어렵게 만들어 놓은 것이다.
문제는 스펙터 취약점 또한 하드웨어 구조적 결함이라 업데이트같은 소프트웨어적 미봉책으로는 사실상 완전히 막을 수 없다는 것이다. 스펙터 버그의 공동 발견자 중 한 명인 폴 코처(Paul Kocher)에 [[7]], 스펙터 버그가 소프트웨어 패치로 해결되지 않는다고 한다. 멜트다운 버그가 긴급한 위기인 반면, 스펙터 버그는 모든 고성능 프로세서에 영향을 끼칠 수 있으며, 성능에 중점을 둔 설계가 이러한 버그에 취약하게 만들었다고 한다. 즉, 성능과 보안을 모두 얻으려던 업계의 갈망이 불가능하다는 것을 보여주는 사례가 스펙터 버그이며 새로운 설계의 프로세서가 나오기 전까지 존재할 것이라고 한다. 스펙터 버그는 수십년간 사용된 프로세서 설계에 존재하는 결함이기 때문이다.
스펙터 버그는 멜트다운 버그에 비해 심각성이 적다고 여겨지지만, 현대의 고성능 CPU 중에 스펙터 버그에 면역인 CPU가 존재하지 않고, 면역이 되기 위해서는 성능을 포기해야 하며[* 베이트레일 이전의 인텔 아톰 시리즈만 봐도 알 수 있다. 순차적 처리만 지원해서 상술했듯 두 취약점이 없다. 물론 성능은 안습 수준.], [정도로 위험한지는 감도 안 잡히는 상황이고, 현재 상황으론 얼마나 완화될 수 있는지도 미지수인데] 근본적인 해결법은 새로운 설계의 CPU 밖에 없어, 가볍게 여겨져서는 안될 것으로 보인다.
인텔 AMT 관련 추가 보안 문제
꺼진 불도 다시 보자
핀란드의 보안 회사 F-Secure[* 여담으로 이 회사는 샤오미社의 홍미 노트에서 중국 정부의 백도어를 발견했던 회사이다.]에서 인텔의 일부 CPU에서 추가로 문제점을 발견했다. 멜트다운, 스펙터 보다 심각한 문제라고 한다. AMT기술은 현재 전세계 약 100만대의 기업용 컴퓨터에 사용되기 때문에 더 큰 파장이 일어날 것이라고 한다.[* 기업용 PC 및 노트북에 사용되는 vPro 테크놀러지에 AMT가 포함되어 있다.]
AMT는 인텔의 기술이므로 AMD, ARM등 다른 제조사의 CPU에는 영향이 없다.
그리고 공격을 위해서는 공격 대상의 PC가 부팅 후 관리자 로그인만 되어있으면[* 해당 문제 설명에서 PC에 물리적 접근이 필요하다는 말이 이것 때문이다. 처음부터 부팅 시의 셋업까지 원격으로 가능한 경우는 거의 없고, 설정에서 풀어 놓아야 한다.] 가능하며, 기본 설정에서는 해당 공격이 불가능하다. 다만 내부 보안이 허술할 경우 PC의 관리 콘솔 관리자 비밀번호를 기본값에서 변경하지 않고, 이후 PC에 허가받지 않은 사람이 접근하여 콘솔 설정을 해 놓는 일련의 상황이 가능할 수도 있다는 것이 문제. [[11]]
사실, 인텔 매니지먼트 엔진과 AMT 관련 취약점은 17년 5월에 한번 공지가 있었고, 해당 내용 관련 윈도우 업데이트는 17년에 이미 진행되었다. 지금 등장한 내용과 이때의 내용은 조금 다른 부분으로, AMT 관련 수정을 했다던 인텔이 다시 한번 뚫림으로써, 상당한 타격이 예상된다.
POS와 키오스크, ATM을 개발하는 미국의 NCR은 인텔 매니지먼트 엔진의 취약점을 이용해 ATM을 원격 공격할 가능성에 대해 언급하였다. 인텔 ME 관련의 원격 서버 관리 버그, Intel Trusted Execution Engine 취약점을 악용해 ATM의 원격 공격이 가능하다고 하는데 이 me관련은 인텔만 사용하기에 인텔만의 문제이다. 스카이레이크/카비레이크 아키텍처 기반 ATM에 국한된 것으로, 이 회사에선 일부 커스텀 오더를 받은 제품에 여기에 해당되기에 한국에서는 해당되지 않는다. [[12]]
스펙터 프라임 / 멜트다운 프라임
엔비디아와 프린스턴 대학 연구팀이 새롭게 발표한 취약점으로 상세 설명은 아직 공개되지 않았다. 멜트다운과 스펙터의 변종으로, 멀티코어 CPU 간의 캐시 일관성으로 인해 발생하는 문제라는 언급만 있었다. 비록 멜트다운 프라임은 실제로 구현하진 못헸지만 스펙터 프라임은 구현에 성공했다. 인텔은 기존 스펙터, 멜트다운 패치가 이 문제에도 일정 부분 적용될 것이라고 한다. AMD가 이번에도 피해갈 수 있을지는 미지수인 상태. 기존 스펙터, 멜트다운을 가지고 있던 X86(특히 인텔), ARM, POWER 아키텍처 CPU는 여기에도 해당될 것으로 보인다. 일각에서 예상했던 패치 릴레이의 시작일 수도 있는 상황(...) [[13]] [[14]]
브랜치스코프
끝날 때까지 끝난게 아니다
윌리엄 메리 대학교, 캘리포니아 대학교 리버사이드, 카네기 멜론 대학교, 빙엄턴 대학교의 연구진이 발견한 새로운 취약점이다. 인텔 SGX(Software Guard eXtension) 안에 보호받고 있는 데이터도 뚫을 수 있다. 스펙터 취약점과 마찬가지로 분기 예측 실행을 통한 취약점이다. 그렇지만 스펙터 취약점은 분기 예측 유닛의 분기 목표 버퍼를 노리지만, 브랜치스코프는 분기 예측 유닛의 패턴 히스토리 테이블을 노리는 취약점이다. 이로 인해 연구진들은 확인해 보진 않았지만 스펙터를 막기 위해 내놓은 인텔의 패치가 브랜치스코프에는 무력할 수 있다고 주장한다. 반면 인텔은 스펙터 Varient 1을 위한 패치가 브랜치스코프에도 유효할 것이라 주장한다. 스카이레이크, 하스웰, 샌디브릿지 i7과 i5에서 취약점이 확인되었다. 그렇지만 연구진들은 AMD CPU에 관한 언급은 하지 않아 AMD CPU는 무사한 건지, 아니면 아직 테스트를 못해본 건지는 알 수 없다. 하지만 스펙터 취약점과 비슷한 루트를 통한 취약점 이기에 스펙터 취약점이 있는 AMD CPU에서도 취약점이 있을 수 있다. 연구원들은 이 취약점을 해결하기 위한 세 가지 대안을 제시했다.
Spectre-NG 추가 발견
끝없는 버그와의 전쟁
새로운 스펙터 취약점이 발견되었다. 인텔 뿐 아니라 소수의 ARM 기반 CPU 및 AMD CPU에도 영향이 있을 수 있다고 한다.
추후 패치 예정에 있다고 한다. 스펙터 varient 4로 부르기도 한다.
L1TF 버그 발견
끝날 때까지 끝난게 아니다 시즌 2 [[18]] [[19]] [[20]]
SMT와 관련된 버그이다. Foreshadow이라는 별명이 붙었다. AMD CPU에는 적용되지 않는다고 한다.
OpenBSD의 리드 개발자 Theo de Raadt는 해당 취약점을 막으려면, 모든 인텔 CPU에서의 하이퍼쓰레딩을 바이오스 설정을 통해 비활성화해야 한다고 메일링리스트에 올렸다.[[21]][[22]] 메일 내용을 보면 표현이 꽤나 과격하다. Fundamentally broken(기초부터가 잘못된), doing a terrible job(일을 엉망으로 하는), There is no time left to (시간이 부족한) 등등... 게다가 아직도 추가적으로 더 밝혀질 건덕지가 있음을 예고했다.[* There will be more hardware bugs and artifacts disclosed. "더 많은 버그와 부산물이 공개될 것이다." Will be는 확정을 의미할 수도 있고 예측을 의미할 수도 있다. 하지만, 하나의 플랫폼을 담당하는 리드 개발자의 위치에 있는 사람이므로 최소한 지금까지 엠바고가 풀린 것보다는 더 많은 정보를 알고 있을 것이다. 따라서 여기서의 will be는 확정적으로 그렇게 될 것이라는 의미라고 볼 수 있다.]
그 와중에 인텔은 L1TF에 대해 제공한 마이크로코드 패치를 배포하면서 "패치 전후 성능을 비교하는 벤치마킹을 해선 안 된다"라는 조항을 EULA에 포함시켰다가 반발이 거세지자 다시 삭제했다.[[23]]
해당 버그에 취약한 하드웨어
스펙터 버그는 동시에 여러 명령어를 처리하는 CPU에서는 공통적으로 발생이 가능하다. 즉, 인텔, AMD, ARM 등 모두 해당된다. 현재까지 완전 면역으로 밝혀진 CPU는 명령어를 순차 처리하는 구형 저성능 CPU들만 존재하는 상황이다.[[24]][* 마찬가지 이유로 알려진 GPU의 경우는 해당사항이 없다. 만약 이들이 취약점에 노출되었다면 권한 없이 타 애플리케이션의 화면를 탈취하는 것이 가능했겠지만, 현존하는 GPU들은 극단적으로 데이터 병렬화를 추구하는 방향으로 발전하였고, 그 덕분에 예측실행과 OoOE 기능을 탑재하지 않았다. 비유하면 한 칩에 구형 CPU를 무식하게 많이 때려박은 것.]
멜트다운 버그에 공식 홈페이지의 [CPU]에서는 아이태니엄과 2013년 이전의 아톰 프로세서를 제외한 모바일, 데스크톱 기종을 불문하고 '1995년 이후 나온 비순차 처리를 이용하는 모든 인텔 프로세서는 잠재적으로 해당된다고 하며, 출시일이 2011년인 모델까지 거슬러 올라가며 테스트한 결과 멜트다운 취약성이 확인되었다고 하였다. 버그 공개 초기의 문서라서 그런지 여기에서는 AMD와 ARM은 확실하지 않다고 하였다.
인텔과 관련하여 해당되는 제품을 좀 더 자세하게 표로 만들면 다음과 같다. || 인텔 CPU 제품군 || 세부 모델 || || 펜티엄 제품군 || Pentium Xxx XXXXX || || 셀러론 제품군 || Celeron XXXXX || || 코어 제품군 || Core Xxxx XXXXX || || 코어 2 제품군 || Core 2 Xxxxxxx XXXXXX || || 코어 i7 제품군 || Core i7-XXXXX || || 코어 i5 제품군 || Core i5-XXXXX || || 코어 i3 제품군 || Core i3-XXXXX || ||<|3> 코어 X 제품군 || Core i9-XXXXX || || Core i7-XXXXX || || Core i5-XXXXX || || 제온 제품군 || Xeon XXXXX || ||<|3> 제온 E 제품군 || Xeon E7-XXXX || || Xeon E5-XXXX || || Xeon E3-XXXX || || 제온 Platinum 제품군 || Xeon Platinum XXXX || || 제온 Gold 제품군 || Xeon Gold XXXX || || 제온 Silver 제품군 || Xeon Silver XXXX || || 제온 Bronze 제품군 || Xeon Bronze XXXX || || 아톰 일부 제품군 || 2013년 이후 출시된 전 제품 ||
즉 P6 아키텍처 이후의 거의 모든 인텔 x86 기반 프로세서가 멜트다운 버그에 취약하다. 테이블에 서술된 펜티엄 제품군은 P6 아키텍처 기반인 펜티엄 프로, 펜티엄 2부터 펜티엄 듀얼코어 시리즈[* 코어 아키텍처 기반의 E 시리즈와 웨스트미어 아키텍처 기반부터 현재까지의 G 시리즈가 이에 해당된다.]까지 해당되고, 셀러론 제품군은 펜티엄 제품군에 사용된 아키텍처에서 파생된 보급형 제품군이기 때문에 P6 아키텍처 기반의 초창기 셀러론 제품군부터 스카이레이크 아키텍처 기반의 현세대 셀러론 제품군까지 모두 해당된다. 2008년부터 2013년 이전에 출시된 본넬 아키텍처 기반의 아톰 프로세서는 비순차실행을 지원하지 않아 해당 사항이 없다. 또한 x86과 호환성이 없는 IA-64 기반의 아이태니엄 프로세서는 x86 아키텍처가 아니라서 해당 사항이 없다.
TECHARP에서도 영향 받는 제품 [[25]]을 제공하고 있다.
1월 6일에는 [[26]](맥,아이폰,아이패드,애플 TV[* 애플 워치는 원천적으로 멜트다운과 스팩터 모두에 영향을 받지 않으며, 나머지 기기들은 17년 12월 6일에 멜트다운 버그 패치를 받았다.]), 닌텐도(스위치)가 3가지 공격 모두에 취약함이 밝혀졌다. 반면 AMD는 유형 2 (스펙터 - BTI), 유형 3 (멜트다운)는 해당하지 않고 유형 1 (스펙터 - BCB)은 긴급패치되었다. [[27]][* 표와 번역 내용에 오류가 있으니 주의.]
닌텐도 스위치의 프로세서(테그라)를 생각하면 NVIDIA까지 불똥이 튈 수도 있는 상황이다. ARM도 점점 심각해지는 게, 유형 3a에 영향받는 '일부'의 목록이 길어지고 있다. 자체 아키텍처로 선회한 삼성 엑시노스, 퀄컴 스냅드래곤은 아직 문제점이 보고되지 않았다.[* 단 자체 아키텍처로 변경하기 전의 모델은 똑같이 영향을 받는다.]
IBM의 IBM System Z, POWER 8(Big Endian and Little Endian)과 POWER 9 CPU(Little Endian)도 멜트다운 버그(CVE-2017-5754)와 스펙터 버그(CVE-2017-5715, CVE-2017-5753)에 취약하다.[[30]]
취약점에 대한 대응
미국 국토안보부, 미국 국방부, FBI의 사이버보안 고문 기관인 CERT/CC는 소프트웨어가 아닌 CPU 아키텍처 자체의 결함이기 때문에 업데이트는 미봉책일 뿐이며, 보안 취약점이 발견된 인텔, AMD, ARM 등의 CPU의 교체가 필요하다는 [[31]]을 내렸다. 하지만 이 권고안은 다음날 [[32]] CERT/CC는 OS, CPU 마이크로코드, 애플리케이션을 업데이트를 하라는 새로운 [[33]]을 내렸다. 프로세서를 교체하는 것이 근본적인 해결책이지만, 추측 실행을 사용하지 않는 고성능 프로세서가 존재하지 않아 현재는 대체할 프로세서가 없기에 지금 당장 사용할 수 있는 해결책은 아니다. 때문에 CERT/CC가 권고안을 철회한 것으로 보인다. 사실 일반적으로 떠올리기 쉬운 CPU제조사로 보더라도 저 범위에서 크게 벗어나지도 않기도 하고 ARM의 경우에는 ARM기반의 CPU를 통칭하다보니 범주에서 벗어나는 CPU를 찾는게 더 어려워진다.
CERT/CC와 동일하게 CPU 교체가 필요하다는 권고안을 내린, 미국 국토안보부 산하의 US-CERT도 해당 권고안을 철회하고 보안 패치를 받으라는 새로운 [[34]]을 내렸다. 또한 보안 취약점이 CPU 아키텍처에 있기 때문에, 패치가 모든 경우의 보안 취약점에 대한 해결책이 되지 못할 수도 있다고 덧붙였다. US-CERT가 권고안을 수정한 이유도 CERT/CC와 같은 것으로 보인다.
구글은 성능저하 없이 스펙터 취약점을 패치 가능한 리트폴린(Retpoline)을 공개했다.[[35]]
인텔
2018년 1월 4일, [공식 성명]이 나왔다. >인텔은 악의적인 목적으로 사용되었을때 시스템에서 민감한 데이터를 탈취할 수 있는 소프트웨어 분석 방식에 관한 새로운 보안 연구에 대해서 인지하고 있습니다. 이번 보안 문제가 데이터를 손상, 수정, 삭제할 잠재력은 없습니다.[* 맞는 말이긴 하다. --쳐맞는 말-- 문제는 메모리의 암호를 유출 가능함으로써 그 암호로 다시 내부 시스템을 위에서 말한 데이터를 손상, 수정, 삭제를 할 가능성은 열려있다.] 보안 문제가 '버그'나 '결함'으로 인한 것으로 인텔 제품에만 존재한다는 것은 잘못되었으며, 인텔 CPU뿐만 아니라 다른 프로세서에서도 나타날 수 있습니다. 인텔은 이러한 보안 문제를 해결하기 위해 AMD, ARM, OS 회사 등과 함께 협력하며 제품과 소비자 보안을 위해 노력하고 있습니다. 보안 패치가 성능에 미치는 영향은 작업량에 따라 다르며, 일반적인 유저에게 있어선 큰 영향이 없을 것이며 시간에 따라 나아질 것입니다[*원문2 Contrary to some reports, any performance impacts are workload-dependent, and, for the average computer user, should not be significant and will be mitigated over time]. 업데이트가 가능해지는 즉시 업데이트를 하시고, 업데이트를 하시기 전까지 악성 소프트웨어를 방지하는 보안 수칙을 따르십시오.
인텔은 자사 홈페이지에 보안 이슈에 대해 정리한 [[36]]을 게시했다. 해당 글에서 인텔은 엔드 유저에게 업데이트가 가능해지는 즉시 업데이트를 할 것을 권장했다. 또한 보안 버그를 악용하는 악성 소프트웨어로부터 시스템을 보호하는데 도움이 되는 보안 수칙으로 다음과 같은 예시를 들었다.[* 내용을 보면 알겠듯이 범용적인 보안 지침 안내이다. 이걸 안 지켜서 사달이 난 것이 불과 몇 개월 전에 벌어진 워너크라이 사태.]
* 컴퓨터 사용 환경을 통제할 것(Maintain control of your computing environment) * 펌웨어/드라이버 업데이트를 주기적으로 확인할 것(Regularly check for and apply available firmware/driver updates) * 하드웨어, 소프트웨어 방화벽을 사용할 것(Use hardware and software firewalls) * 사용하지 않는 서비스를 끌 것(Turn off unused services) * 적절한 사용자 권한을 유지할 것(Maintain appropriate user privileges) * 보안 소프트웨어를 최신 상태로 유지할 것(Keep security software up to date) * 알지 못하는 링크 클릭하지 말 것(Avoid clicking on unknown links) * 여러 사이트의 패스워드를 같은 것으로 사용하지 말 것(Avoid re-using passwords across sites)
인텔의 CEO 브라이언 크르자니치(Brian Krzanich)는 [[37]]에서 이번 보안 이슈는 해결 불가능한 문제가 아니기 때문에 리콜은 없을 것이라고 밝혔다. ~~그래서 넌 니 주식 다 처분했고?~~
2018년 1월 5일, 인텔은 두 개의 기사를 자사 홈페이지에 게시했다.
[번째 기사]에서 인텔은 자사 시스템에서 멜트다운 버그와 스펙터 버그를 막을 수 있는 업데이트를 개발했으며, 배포하고 있다고 밝혔다. 인텔은 지난 5년간 출시된 대부분의 프로세서를 위한 업데이트를 이미 배포했으며, 다음주 말까지 지난 5년간 출시된 프로세서의 90% 이상을 위한 업데이트가 배포될 것이라고 밝혔다. 또한 많은 OS 회사, 공공 클라우드 서비스 제공 업체, 디바이스 제조사 등과 같은 업체들은 이미 제품과 서비스를 업데이트했다고 밝혔다. 성능 저하 이슈에 대해서는 작업량에 따라 다르며, 일반 유저들에게 있어선 큰 영향이 없을 것이며 시간에 따라 나아질 것이라는 기존 입장을 고수했다. 일부 특정한 작업량에서는 성능 저하가 다른 작업량에 비해 초기에는 높을 수 있지만, 테스트와 소프트웨어 업데이트의 개선 등으로 성능 저하를 완화시킬 것이라고 밝혔다.
[번째 기사]에서 인텔은 파트너사와 함께 멜트다운 버그와 스펙터 버그 보안 패치가 성능에 주는 영향을 측정하는 대규모 테스트를 진행하고 있다고 밝혔다. 또한 인텔은 성능 하락이 거의 없거나 전무하다고 밝힌 애플, 아마존, 구글, 마이크로소프트의 조사 결과를 인용했다. 인텔은 성능 저하는 작업량에 따라 다르며, 일반적인 유저들에게 있어선 큰 영향이 없을 것이며 시간에 따라 나아질 것이라는 기존 입장을 다시 한번 더 고수했다.
2018년 1월 9월, 인텔의 CEO 브라이언 크르자니치는 CES 2018 [기조연설]을 멜트다운 버그와 스펙터 버그에 대한 언급으로 시작했다. 크르자니치는 여러 프로세서 아키텍처에 존재하는 업계의 보안 이슈를 해결하기 위해 수많은 기업들이 협력한 것은 정말 놀라웠다고 밝혔다. 크르자니치는 이어, 인텔이 보안 문제를 해결하기 위해 노력하고 있으며, OS 회사와 시스템 제조사의 업데이트를 가능한 빠르게 받는 것이 데이터를 안전하게 보호하는데 최선의 행동이라고 밝혔다. 또한 일주일 동안 5년간 출시된 프로세서와 제품의 90% 이상을 위한 업데이트가 배포되었으며 1월 말까지 나머지 제품을 위한 업데이트가 배포될 것이라고 밝혔다. 성능 저하는 작업량에 따라 매우 다르며, 일부 특정한 작업량에서는 성능 저하가 다른 작업량에 비해 높을 수 있지만, 업계와 노력해서 지속적으로 성능 저하를 최소화시킬 것이라고 밝혔다.[* 연설문 전체는 [[38]]에서 볼 수 있다.]
해당 연설에서 크르자니치의 '수많은 기업들이 협력한 것은 정말 놀라웠다.'라는 발언이 자화자찬이 아니냐는 [[39]]가 있다.[* 해당 기사에서 자화자찬 논란이 일고 있다고 했지만, 해외의 반응을 보면 보안 이슈와 사과가 없다는 것에 더 논란이 일고 있다. 이후 인텔 홈페이지에 올라온 [[40]]를 보면, 크르자니치가 이러한 표현을 사용한 것은 자화자찬이라기보다는 보안 이슈를 발견해주고, 해결하기 위해 협력해준 업계에게 감사를 표하기 위해 사용한 것으로 보인다.] 또한 보안 이슈에 대한 사과가 없다는 점을 꼬집은 [[41]]이 있다. 크르자니치의 발언은 자화자찬으로 들릴 수 있고, 사과가 전혀 없으며, 보안 문제가 완전히 해결되었다는 듯한 뉘앙스를 가져 커뮤니티의 반응이 매우 부정적이다.
2018년 1월 10일, 인텔은 보안 이슈에 관한 [[42]]를 자사 홈페이지에 게시했다. 해당 기사에서 인텔은 현재까지 멜트다운 버그와 스펙터 버그를 이용한 어떠한 데이터 탈취도 발견되지 않았다고 밝혔다. 인텔은 12월 초에 OEM 파트너사에게 인텔 펌웨어 업데이트를 제공하기 시작했으며, 일주일 동안 5년간 출시된 프로세서와 제품의 90% 이상을 위한 업데이트가 배포되었으고, 1월 말까지 나머지 제품을 위한 업데이트가 배포될 것이라고 밝혔다.
인텔은 최근의 PC 성능 테스트에 근거하여, 일반적인 컴퓨터 사용자에게 큰 성능 저하가 없을 것이라고 밝혔다. 또한 일반적인 가정과 비즈니스 PC 사용자들은, 이메일 읽기나 서류 작성 혹은 디지털 사진을 엑세스 하는 것 같은 일반적인 작업에서 큰 성능 저하를 겪지 않을 것이라고 밝혔다. 인텔은 SYSmark 2014 SE 테스트에서 SSD와 8세대 코어 프로세서가 장착된 컴퓨터에서 6%나 그보다 적은 성능 저하를 보였고 SYSmark의 개별 테스트에서는 2%에서 14%의 성능 저하를 보였다고 밝혔다. 데이터 센터의 성능 저하는 현재 조사하고 있는 중이며 클라우드 서비스 등을 제공하는 여러 업계 파트너사의 조사에서는 성능 저하가 작거나 거의 없다는 결과가 나왔다고 밝혔다.
전반적인 성능 저하는 특정 작업량, 플랫폼 구성, 성능 완화 기술에 따라 다르다고 밝혔다. 또한 경우에 따라 여러 가지 성능 완화 옵션이 있으며, 각각 성능에 미치는 영향과 구현 세부사항이 다르다고 밝혔다. 더 많은 자세한 내용은 인텔의 [[43]]와 구글의 "레트폴린(Retpoline)" 보안 솔루션 [[44]]에서 찾을 수 있다고 밝혔다. 인텔은 업계와 함께 성능 저하가 큰 경우를 해결하는 해결법을 계속해서 찾고 있다고 밝혔다.
2018년 1월 11일, 인텔은 클라이언트 시스템의 초기 성능 테스트 [[45]]를 공개했다. 서버 플랫폼의 초기 성능 저하 테스트 데이터는 며칠 뒤에 공개하겠다고 밝혔다. 윈도우 10과 SSD를 사용하는 8세대 인텔 코어 프로세서(카비레이크-R, 커피레이크) 플랫폼에서 성능 저하는 6퍼센트이며(SYSMark 2014 SE 벤치마크), 일부 경우에는 최대 10퍼센트의 성능 저하가 있을 수 있다고 밝혔다. 윈도우 10과 SSD를 사용하는 7세대 카비레이크-H 모바일 플랫폼에서는 8세대 인텔 코어 프로세서 플랫폼과 비슷한 약 7퍼센트의 성능 저하(SYSMark 2014 SE 벤치마크)가 있다고 밝혔다. 윈도우 10과 SSD를 사용하는 6세대 스카이레이크-S 플랫폼에서는 이보다 약간 더 높지만 7, 8세대 플랫폼과 비슷한 8퍼센트의 성능 저하(SYSMark 2014 SE 벤치마크)가 있었다고 밝혔다. 같은 6세대 플랫폼에서 윈도우 7을 사용했을때는 약 6퍼센트의 성능 저하(SYSMark 2014 SE 벤치마크)가 있었으며, HDD를 사용했을때는 이보다 성능 저하가 더 낮았다고 밝혔다.[* 더 자세한 내용은 [[46]]에서 볼 수 있다.] 인텔은 추가 테스트를 수행할 때 마다 결과가 변경될 수 있다고 덧붙였다.
인텔은 광범위한 용도와 인텔 플랫폼의 성능 테스트 결과를 모으고 있으며, 다음주 안에 지난 5년간 출시된 모바일, 데스크탑 플랫폼의 데이터를 제공할 것이라고 밝혔다. 인텔은 업계 파트너사와 함께 성능 저하를 가능한 줄이기 위해 여러 해결책들을 만들고 있으며, 현재 출시된 제품 뿐 아니라 미래에 출시할 제품의 보안과 성능을 극대화하기 위해 노력하고 있다고 밝혔다.
2018년 1월 12일, 인텔 CEO 브라이언 크르자니치는 자사 홈페이지에 기술 업계 선두 기업을 위한 [[47]]을 올렸다. 글에서 크르자니치는 1월 말까지 지난 5년간 출시된 제품의 업데이트를 마치고 그후에는 구형 제품의 업데이트를 배포하겠다고 말했다. 이어, 인텔 홈페이지에 지속적으로 보안 패치 진행 상황과 성능 데이터 등을 게시할 것이라고 말했다. 마지막으로, 모든 업계의 보안을 강화하기 위해 중요한 보안 취약점은 공개적으로 밝히고, 업계와 협력하며 사이드 채널 공격(side-channel attacks)을 방지하는 하드웨어 혁신을 업계와 공유할 것이며, 잠재적인 보안 위협 연구를 위한 연구에 기금을 지원할 것라고 말했다.
2018년 1월 12일, 인텔은 몇몇 시스템 특히 하스웰과 브로드웰 시스템에서 펌웨어 업데이트를 적용한 후 자주 재부팅 현상이 일어난다는 보고가 있었으며, 만약 이 문제가 개선된 펌웨어 업데이트를 필요로 한다면 제공할 것이라고 밝혔다. [[48]]
2018년 1월 21일, 리눅스의 아버지인 리누스 토르발스가 인텔이 내놓은 패치 내역을 검토하고 이에 대한 평가를 하였는데, 취약점 보완 상태를 선택적으로 취할 수(통보할 수) 있게 설정해둔 사실을 발견하였다. [[49]] 다시 말해서 멜트다운 보안 패치는 단순히 수정하는 것으로 끝나지만 '스펙터'의 경우 OS 에게 수정 사항을 활성화할 건지 말건지 OS에 선택권을 제공하고 있다는 뜻인데, 리누스는 해당 스펙터 패치가 성능 저하를 일으키기 때문에 벤치마크에서 이 것이 반영될 부분을 의식해서 켜고 끌 수 있게 남겨두었다고 말하면서 이번 패치를 쓰레기라고 비판하였다.[*원문3 As it is, the patches are COMPLETE AND UTTER GARBAGE] 즉, 인텔은 성능 저하가 없어야하는 스펙터 패치에서마저 성능 저하가 일어나고, 이를 숨기기 위해 벤치마크에는 OFF 상태에서 측정한 값을 결과랍시고 발표한 것이다. 이외에도 무한 재부팅 등 발견된 문제점이 한두가지가 아니었고, 결국 인텔은 자사가 직접 만든 스펙터 패치를 자사 제품 사용자들에게 사용하지 말라고 권고하는 상황까지 왔다. [[50]]
2018년 1월 26일 인텔은 보안을 강화하여 칩셋을 새로 내기로 하였다. [[51]], [gear] 근본적인 해결책인 재설계가 아닌 다른 방식을 사용을 함으로서 보안을 좀 더 강화를 하겠다는 것이나, 실질적으로 아키텍처를 새로 만든 것이 아니기 때문에 완전한 해결은 불가능하며, 인텔에게서 최대 문제인 멜트다운 부분을 해결할 것으로 보인다. 보안장치를 내장하는 방식이며, 보드나 cpu에 포함되기에 보안을 강화시키려면 AMD 등으로 교체하지 않는 이상 8세대 커피레이크 포함한 모든 프로세서가 교체대상이지만 기존 인텔 사용자에겐 그 어떠한 보상도 없다.
2018년 2월 22일 6 ~ 8세대 문제 수정 마이크로 코드가 배포되었다. 3월 3일에는 4, 5세대 문제 수정 마이크로 코드 업데이트가 실시되었다. 3월 13일 2, 3세대 마이크로코드 업데이트가 배포되었다. 마이크로코드 업데이트는 기본적으로 메인보드 펌웨어에 첨부되는 방식이라 메인보드 제조사/PC 제조사가 업데이트해야 되므로 사실상 최신 제품 외에는 업데이트를 받기 어렵다.[* 기업용 제품이나 서버는 지원기간이 더 길기에 마이크로코드 업데이트가 이루어질 제품이 더 많을 것이다.]
2018년 4월 [마이크로코드 업데이트 가이드]에 따르면 블룸필드, 블룸필드 제온, 클락스필드, 걸프타운, 하퍼타운 제온 C0, 하퍼타운 제온 E0, 재스퍼 포레스트, 펜린/QC, SoFIA 3GR 아톰, 울프데일 C0, 울프데일 M0, 울프데일 E0, 울프데일 R0, 울프데일 제온 C0, 울프데일 제온 E0, 요크필드, 요크필드 제온을 포함한 과거 제품에 대해 마이크로코드 업데이트를 중단, 포기한 것으로 보인다.(세대를 잘 보면 알겠지만, 걸프타운을 제외한 웨스트미어 세대(웨스트미어,클락데일,애런데일)부터 패치하고, (걸프타운을 포함하여) 그 이전 세대는 모두 버렸다.)
AMD
한편 AMD 측의 분석 결과 [[52]]에 의하면, 구글 프로젝트 제로팀에서 언급해 준 취약점 중 스펙터 버그에 해당되는 "경계검사 우회(Bounds Check Bypass)" 변수는 OS/소프트웨어 업데이트로 해결이 되었으며 업데이트로 인한 성능 저하는 무시할 수 있는 수준이라 하였고, "분기표적 주입(Branch Target Injection)" 변수는 아키텍처 구조 상 문제 발생 가능성이 매우 낮으며, 아직까지 성공이 확인된 사례는 없다고 하였다. 그리고 멜트다운 버그에 해당되는 "불량 데이터 캐시 적재(Rogue Data Cache Load)" 변수의 경우도 마찬가지로 아키텍처 구조의 차이로 문제가 없다고 하였다.--갓 AMD--
분기표적 주입의 경우, 아직 공격 성공 사례는 없지만, 문제가 되는 추측 실행의 근본적인 원리는 AMD에도 해당되므로 선택적 마이크로코드 업데이트를 내놓기로 했다.[*원문4 AMD will make optional microcode updates available to our customers and partners for Ryzen and EPYC processors starting this week. We expect to make updates available for our previous generation products over the coming weeks. These software updates will be provided by system providers and OS vendors; please check with your supplier for the latest information on the available option for your configuration and requirements. 출처는 위에 적힌 발표 링크] [[53]] (14번째 댓글 참고)
이것저것 피하면서 어떻게든 대미지 컨트롤부터 하려고 했던 인텔과 달리, 비전문가도 읽고 이해할 수 있도록 아주 깔끔한 해명을 해서 간만에 AMD PR이 일 잘했다는 칭찬이 나왔다. 참고로 ARM 홀딩스도 대응이 괜찮았다고 한다.
그리고 [ZEN과 ZEN+ 아키텍처에서는 마이크로 패치로 대응을 하며, 2019년에 나올 ZEN 2 아키텍처에서는 하드웨어 구조 변경을 통한 스펙터 완전 대응을 예고했다.]
OS
리눅스 커널에는 패치가 적용된 상태다. 처음 멜트다운 취약점 해결 패치가 적용된 리눅스 커널은 아키텍처에 관계 없이 기본적으로 해당 보안 기능이 실행되기 때문에 성능저하를 막기 위해서는 커널 옵션에서 이 기능을 꺼 줘야 했으나[* [[54]]], [패치]가 나오면서 인텔 CPU에서만 실행되도록 변경되었다.[* 어떤 인텔 엔지니어가 그냥 모든 CPU에 패치가 적용되게 만들었다가 리누스 토르발스한테 걸려서 [구수한 쌍욕을 얻어먹기도 했다.] 쌍욕 먹어도 할 말 없는 문제다. 자사의 문제점을 해결하는 패치로 타사의 제품까지 성능을 낮췄으니. --인텔에서 물타기 시전한걸 생각해보면 엔지니어 개인이 결정한것은 아닌것 같다--]
마이크로소프트에서 사태가 정말로 시급하기에[* 윈텔이라는 말이 있을 정도로 Microsoft Windows와 인텔은 서로 떼어놓을 수 없는 관계다.], 원래 정기 업데이트로 예정한 날짜였던 1월 9일이 아닌, 한국 날짜 1월 4일 오전 6시에 윈도우 10에서만 긴급 업데이트를 실시하였다. [기사] [내용 추가 설명][* 당시 마이크로소프트는 다른 운영체제는 1월 9일에 패치가 나올 거라고 했는데 이건 자동 업데이트 기준이었던 모양으로, 1월 4일에 다른 운영체제도 수동 업데이트는 나왔다. 1월 9일엔 윈도우 10 이외의 운영체제도 자동 업데이트로 업데이트가 된다.]
[11월 경 MS측에서 해당 문제에 대한 확인이 진행되었다. 알렉스 이오네스쿠 트위터] 맥의 경우 17년 12월 6일에 정식 보안 패치가 완료되었다. 파일:스크린샷 2018-01-05 오후 7.10.07.jpg [High Sierra 10.13.2의 보안 콘텐츠, 보안 업데이트 2017-002 Sierra 및 보안 업데이트 2017-005 El Capitan에 관하여]
웹 브라우저, 그 외
기계어로 번역되는 자바스크립트를 통해 버그를 트리거할 수 있다는 점이 알려지면서 주요 브라우저들이 임시 방편을 적용했다. 브라우저 수준에서 취약점을 막긴 어렵지만, 공격이 나노초 단위의 정밀한 시계를 필요로 하기 때문에 우선 시계의 정밀도를 임시로 낮춰 놓은 것이다. (취약점이 여전히 남아 있지만 공격 속도를 수천배 이상 낮출 수 있다.) 각 브라우저 별 상황은 다음과 같다.[* [CPU 보안결함 대응 나섰다]]
* 모질라 파이어폭스 57.0.4 (1월 4일 발표) * 네이버 웨일 v1.0.39.11 (1월 11일 발표) * 구글 크롬 64 (1월 23일 발표) * 윈도 7/8.1/10용 인터넷 익스플로러 및 엣지 (1월 3일 발표)
사용자가 할 수 있는 대처법
취약 여부 확인
윈도우에서는 MS에서 공개한 파워쉘 스크립트를 통해 확인할 수 있다. [[55]] PowerShell을 관리자 권한으로 실행 후 아래 명령을 한줄 씩 차례대로 입력한다. 당연히 앞의 PS>는 빼고 입력해야한다. 중간에 모듈 설치를 물으면 Y를 입력한다. {{{ PS> Install-Module SpeculationControl PS> $SaveExecutionPolicy = Get-ExecutionPolicy PS> Set-ExecutionPolicy RemoteSigned -Scope Currentuser PS> Import-Module SpeculationControl PS> Get-SpeculationControlSettings PS> Set-ExecutionPolicy $SaveExecutionPolicy -Scope Currentuser }}} 한줄이라도 붉은색 텍스트가 표시된다면 조치가 필요한 것이다. 취약하지 않거나 대응 조치가 완료되었다면 녹색 텍스트가 표시된다. 각 항목의 의미는 [[56]]
[멜트다운 CPU 체크 프로그램]으로 테스트 해볼 수도 있다. [기사] 다운로드한 파일을 실행한 뒤 start security check 버튼을 누르면 된다. update_ash.exe 파일만 생성되고 실행이 되지 않는다면, 작업관리자로 강제종료한 다음, 파일 속성에 들어가서 차단 해제를 해주고, update_ash.exe 파일 삭제후 다시 실행하면 된다.
[라는 프로그램도 있다.] 취약점 확인 외에 성능 저하를 대략적으로 확인해주는 기능도 존재한다. 특이하게도 취약점 대비를 켜거나 끄는 기능도 존재한다. 취약점 대비가 안되었거나 하드웨어 자체에 취약점이 없는 경우 해당 기능이 활성화되지 않는다. 기능 자체는 MS가 패치에 포함한 기능으로 레지스트리를 통해 조절한다. 그냥 개인도 버튼 하나만 눌려서 쓰기 쉽게 해주는 프론트엔드인 것. 참고로 끈 다음에 그냥 재실행하면 계속 켜져있는 것으로 나올 때가 있는데, 이럴 때는 윈도우를 재부팅한 후에 다시 실행해 보면 정상적으로 반영되는 것을 볼 수 있다.
메인보드 펌웨어 업데이트
프로세서 제조사가 업데이트된 마이크로코드를 제공하고 메인보드 제조사가 그 마이크로코드를 탑재한 펌웨어를 공개, 그리고 최종적으로 사용자가 그 펌웨어를 자신의 메인보드에 업데이트해야한다.[* 멜트다운과는 달리 스펙터는 커널 수정만으로 방어가 불가능하며, 펌웨어 패치까지 이루어져야 가능하다.] 최신 펌웨어라고 해도 2018년 이전에 공개되었다면 취약점이 해결되지 않았을 확률이 높다. 스펙터 대응 펌웨어는 2018년 1월 현재 소수 모델에 겨우 배포되기 시작했다. 쉽게 말해 구형 마더보드를 쓰고 있다면 안타깝게도 현재로서는 메인보드 교체만이 답이라는 것이다. 그나마 CPU 소켓과 RAM 소켓 규격 모두 기존과 일치하는 최신 메인보드가 있으면 다행이지만, 아니라면...
인텔에서는 5년 내에 출시된 CPU에 대해서 업데이트를 제공하겠다고 발표[[57]]했으며 이후 취약점을 해결한 마이크로코드를 배포했다. 2013년 출시된 아이비브릿지 EP/EX 및 하스웰 이후 CPU들에 해당.[[58]]
참고로, 기가바이트의 GA-B150M-D3H 메인보드의 경우 1월 16일 CPU 마이크로코드를 업데이트한 새 버전의 펌웨어가 올라왔는데, 펌웨어 업데이트 전에는 스펙터에 취약하고 멜트다운에는 안전하다는 결과가 나왔는데 (윈도 10 보안 패치는 적용한 상태) 펌웨어를 업데이트한 후 스펙터 멜트다운 CPU 체크 프로그램을 돌리니 스펙터와 멜트다운에 모두 안전하다는 결과가 나온다.
현재 메인보드 주요 제조사 ASUS, GIGABYTE, MSI에서는 9 시리즈(5세대)까지 새로운 펌웨어를 제공하겠다고 밝힌 바 있다. 하지만 9 시리즈는 3사 모두 X99 칩셋만 해당되어 사실상 4세대 하스웰-E모델 및 5세대 브로드웰 이후로만 가 될 것으로 보인다. ASRock은 8시리즈(4세대)까지로 공지가 올라왔는데 지켜봐야 할듯.
한편, HP에서는 자사 제품들에 대해 2월 중에 모두 패치하겠다는 입장을 견지하였지만, 어느 순간 패치들이 줄줄이 취소되며 '인텔 측에서 개선된 마이크로코드를 내놓지 않으면 우리는 업데이트가 불가능하다'는 답변을 내놓았다. 업데이트 일정이 적혀 있던 [문서]는 날짜만 줄줄이 TBD[* To be determined: '미정'을 의미하는 사무적 표현이다.]로 교체된 채 방치되어 있다. 일단 인텔에서 코드를 줘야 패치가 가능한 사정상 어쩔 수 없는 것은 알겠지만, 인텔과 다를 바 없이 너무 무성의한 태도라는 것이 중론. 때문에 HP 사용자들이 공식 포럼을 통해 끊임없이 항의하고 있다. 그런데 문서가 갱신된 4월 11일 기준 일부 제품을 제외한 90% 이상의 제품들의 업데이트가 올라왔다고 문서가 수정되었다. 또한, 아직 업데이트가 나오지 않은 제품들은 TBD가 아닌 Pending으로 상태가 변경되었다. 위 링크로 들어가 자신의 모델을 검색 후 펌웨어 버전에 Pending이나 TBD가 아닌 버전명이 적혀있을 경우 반드시 업데이트 하자. HP Support Assistant를 이용해도 되지만 업데이트가 뜨지 않을 때에는 직접 홈페이지에서 펌웨어 업데이트를 다운받아 업데이트하면 정상적으로 적용이 된다. 적용 후에는 멜트다운과 스펙터에 취약점이 없다는 결과가 나오는 것을 확인하였다.
2018년 3월 31일 기준으로 ASUS B150M-A 메인보드의 경우 새 버전의 펌웨어가 제공되었다. 펌웨어 업데이트 결과 관련 프로그램을 통해 확인된 결과에 따르면 멜트다운과 스펙터 모두 안전하게 나왔다. 참고로 새로운 펌웨어를 업데이트 하기전에는 스펙터에는 취약하다는 결과가 나왔다.[* 윈도우 보안 업데이트, 2017년 11월 지원된 마이크로코드, 펌웨어 업데이트를 진행한 상태에서 그랬다. 그러나 새로운 펌웨어 업데이트 결과 모두 안전하게 나왔다. ]
인텔 아톰 시리즈 중 클로버트레일 이후 CPU는 제조사에서 해당 펌웨어 업데이트가 없는 것 같았지만, 3월 30일 기준 8인치 윈도우 태블릿의 대명사였던 델 베뉴 8 프로가 해당 취약점이 패치된 마이크로코드를 적용시킨 펌웨어 업데이트가 나왔다. 펌웨어 적용 후 검사해보니 안전하다고 결과가 출력된다. 다른 윈도우 태블릿들도 해당 제조사의 홈페이지에 들어가 반드시 펌웨어 업데이트가 있는지 확인한 후 적용하자.
보증기간이 지난 세대 보드의 경우 업데이트를 안 해주는 경향이 있다.[[59]](ASUS고객 센터 답변을 받은 사람이 포럼에 올린 것이다. 내용은 펌웨어 업데이트는 안 해줄 꺼지만 인텔에서 마이크로코드 패치는 해줬으니 사용자가 알아서 리눅스 깔아서 리눅스 패치를 통해 적용하라는 얘기) 보다 못한 VMware제작사가 해당 패치를 윈도우 드라이버 차원에서 끌어다 설치할 수 있는 방법을 개발했다.[[60]] 가상화 기능 개발사이다보니 리눅스용 패치를 윈도우 드라이버에다 끌어붙인 모양.
다른 패치는 안하고 메인보드 펌웨어만 업데이트 했을시 성능하락있는지 아시는 위키러는 추가바람.
윈도우
윈도우 7, 8.1, 10의 경우 2018년 1월 이후에 나온 누적 업데이트 롤업을 설치하면 멜트다운 패치가 된다. 차례대로 설치할 필요없이 최신 버전의 누적 업데이트 하나만 설치하면 된다. 자동 업데이트 기능을 켜놨다면 대개 알아서 해당 업데이트가 설치된다. 만약 설치가 되지 않을 경우 마이크로소프트 카탈로그 사이트에 들어가 자신에게 맞는 업데이트를 설치한 뒤, 재시작하면 된다. Win + R키를 눌러 실행 창을 띄운 뒤 Winver를 입력하면 창이 하나 뜨는데, 버전 xxxx라고 나온 번호가 자신의 버전이다.
이외의 윈도우 운영체제는 [[61]] 받으면 된다. 윈도우 서버제품군은 일반버전이 있고, XP는 패치가 없으나 POSready의 패치를 이용하는 방법이 있다고 한다. 키를 고쳐서 POSready 버전으로 인식한 다음, 보안 업데이트를 진행하는 방법인데, 바로 설치하면 문제가 생기기 때문에 우선 일반용을 설치한 다음, 레지스트리를 수정해 POSready를 올리는 식으로 했다는 말도 있다. 비스타의 경우 서버 2008용을 올리면 설치된다.
스펙터의 경우 펌웨어 업데이트로 해결해야 되나, MS에서 따로 마이크로코드 업데이트를 공개했다. 현재는 인텔 코어 i 제품군 4 ~ 8세대 CPU만 지원하며 윈도우 10 전용이다. 이전 버전은 여전히 펌웨어 업데이트를 해야 된다. 해당 업데이트는 자동 업데이트로 배포되지 않기에 직접 다운로드후 설치해야 하며 펌웨어 업데이트가 이루어진 경우 굳이 설치할 필요는 없다. 다만 RS5부터는 스펙터 패치가 기본 내장된다고 한다.
18년 5월 17일에 버전1803용 패치가 나왔다. 이전 패치들과 달리 샌디브릿지까지 지원 대상이 확대되었다. [[62]] 21일에는 이전 패치들도 샌디브릿지까지 지원으로 업데이트된 버전이 나왔다.[[63]], 7월 25일 다시 업데이트된 버전으로 교체되어 나왔다.[[64]]
8월 22일 또 새버전이 나왔다.[[65]] 이번 패치는 L1TF까지의 변종에 대응하기 위해 나온 것이라 기존 패치를 설치한 경우에도 설치해야 되는 것으로 보인다.
|| RTM[* LTSC(舊.LTSB) 한정] || [[66]] || || 버전 1607 || [[67]] || || 버전 1703 || [[68]] || || 버전 1709 || [[69]] || || 버전 1803 || [[70]] ||
업데이트 이후 일부 PC에서는 [[71]]를 인식할 수 없는 오류가 발생해 DAEMON Tools를 비롯한 상당수의 가상 CD 이미지 파일 프로그램들을 사용할 수 없게 되는 문제가 있었다. 다행히 얼마 뒤 2018년 1월 19일, SPTD가 업데이트되어서 최신 SPTD를 설치하면 문제가 해결된다. --하지만, 초창기에 출시한 윈도우 들이나, 9x 계열의 윈도우 들이나, XP 까지의 NT 계열의 윈도우 들은 DAEMON Tools이 되고 안되고의 문제가 전혀 아닌지라...--
macOS
Mac App Store에서 업데이트를 통해 High Sierra 10.13.2를 설치하면 된다. 초기에는 하이 시에라만 멜트다운 패치까지 제공되고 시에라와 엘 케피탄은 스펙터 패치만 제공되었지만, 1월 23일에 해당 버전들을 위한 멜트다운 패치가 공개되었다. 2018-001 보안 업데이트를 설치하면 된다. [[72]], [[73]]. 요세미티 이하 버전은 패치가 제공되지 않는다.
리눅스
리눅스도 배포판 업데이트를 하면 된다. 애초에 이 버그는 이렇게 빨리 공개될 예정이 아니었고, 오픈 소스인 리눅스 커널을 패치하던 중 수상한 패치 요약이 개발자들의 의심을 사는 바람[* 버그를 모르는 사람이 보기엔 합리적인 근거 없이 I/O 성능을 대폭 깎아먹는 패치가 올라온 것이니 의심할 수밖에 없다.]에 빨리 공개된 것이다. 즉, 리눅스에선 버그 발표보다 패치가 올라온 게 더 빨랐다. 물론 각종 Linux 배포판들이 새로운 커널을 공식 지원해서 업데이트를 유도하고 설치하는 건 별개의 일이라 발표 전 미리 리눅스 서버들에 대비가 되어 있었다는 건 아니다.
사건 여파
보안 패치 후 하드웨어 성능 하락
하드웨어의 취약점이기 때문에 이를 OS와 커널 등 소프트웨어 수준에서 해결하려면 성능 하락이 발생하게 된다. [보안 버그 패치 시 성능 저하를 피할 수 있는 방법은 없다고 전문가들이 전했으며], 일부 유저들은 1월 9일 뒤에 상황을 보고 나서 더 논해보자는 신중론을 보이고 있다.
취약점이 공개되기 전 레딧에서 언급된 테스트 결과는 상당한 성능 하락을 보였기에 큰 논란이 되었다. [테스트 결과] [테스트 결과]
역시 실제 패치가 진행되기 전 인사이더 패스트링 빌드로 올렸던 윈도우 10 RS4 17035로 [결과도] 비슷했는데 읽기 속도도 감소했지만, 쓰기 속도의 경우 심각하게 감소했음을 확인할 수 있다. 다만 이는 960 EVO 특유의 캐시 특성에 따른 결과일 확률이 높다. 캐시 메모리를 다 사용한 후 유동적으로 적용되기 때문에 값이 요동친다는 주장이며 이 말대로라면 패치 이전 값 역시 편차가 클 것이고 실제로 MLC인 950 Pro, 960 Pro로 측정했을 시 패치 이후 심각한 성능 하락은 없다. 위 유튜브 링크 중 950 Pro로 측정한 값이 있는데 실제로 16K에서 약간 하락한 것 빼곤 거의 차이가 없다. 또한 패치 RS4 17035 테스트의 경우는 보안패치 이외에 기능업데이트로 인한 영향일 수도 있다.같은 삼성의 850 EVO의 경우도 업데이트 전후로 읽기, 쓰기 속도가 모두 20% 가까이 하락한다는 벤치 결과가 있다. [[74]] 850 EVO 역시 TLC와 캐시 구조를 가진다. SATA 버전의 경우 일부 항목은 변화가 없는 경우도 많다.
다만, NVMe 형식의 SSD의 경우는 그보다 더 하락폭이 더 커졌으며, 성능이 높을수록 그 폭은 더 커진다. SATA와 비교해서 PCIe 컨트롤러를 통해서 CPU와 직결되기 때문인 것도 있지만 , SATA 형식의 SSD와 비교해서 속도 자체가 더 빠르기 때문에 그 폭이 더 커진 것으로 추측된다.
패치 이후에는 다소 다른 결과가 나오기 시작했는데 가장 논란이 되었던 성능 하락을 확인하기 위한 유튜브에 올라온 업데이트후 진행된 벤치마크 결과 영상이다. [[75]] 전반적으로 1~2% 정도의 차이를 보이며 특정 벤치마크는 업데이트 후가 더 잘 나오기도 한다. 측정 편차에 의한 오차를 감안하면 일반사용에 있어서 크게 영향을 느끼기 어려울 것으로 판단된다. 단 개인마다 컴퓨터 사양의 차이가 있어 영상결과와 다를 수 있으며, 16K 영상의 쓰기, 읽기 속도가 약 10% 정도 하락한 것을 보면 대용량 미디어 정보를 관리하는 서버는 영향을 어느 정도 받을 듯 보인다.[* 물론 서버환경에 IO만 영향을 주는 것은 아니기에 클라이언트 사용자 기준에선 체감이 없을 가능성도 있다.]
SSD보다 메모리를 벤치를 비교해야 된다는 얘기가 있다. [[76]], [[77]]
[성능팀이 Red Hat Enterprise Linux 7을 기준으로 벤치마크한 결과를 공개했다.] 요약하자면, 아래와 같다.
* Measureable: 8~19% - Oracle OLTP, MariaDB, PostgreSQL, fio(Random IO to NVMe)와 같은 buffered IO와 cached random memory access, OLTP DB 환경 * Modest: 3~7% - DW성 업무(Analytics), Java VM, MongoDB 등 * Small: 2~5% - HPC와 같은 CPU intensive 업무
IBM에 [[78]], 성능 하락은 작업량과 시스템 환경에 다르다고 한다. 예를 들어 순수하게 메모리 기반 연산을 하고 최소한의 소프트웨어만 구동되는 텍스트 기반 환경에서는 큰 성능 하락이 없을 것이며, 많은 저장 장치와 네트워크가 연결이 되었으며 주로 정보 저장소로 사용되는 GUI 시스템에서는 큰 성능 하락이 있을 수 있다고 한다.
현재까진 게임 성능에는 가시적인 저하가 없는 것으로 확인되었다. 업데이트를 받아보고 즉시 벤치를 돌려본 유저들의 의견에 의하면 성능상으로 큰 차이는 없다는 언급이 대부분이다. 게임은 소프트웨어를 보조기억장치에 설치해 놓고 실시간으로 리소스를 읽어오는 방식인데 위의 서술대로 쓰기 속도가 저하된다고 해도 읽기가 대부분인[* 세이브, 스크린샷, 설정 변경 등 소수 기능은 쓰기를 이용하지만 이러한 작업은 전체적인 게임 진행 중 매우 일부분만 차지하기 때문에 별 상관이 없다.] 게임엔 영향을 미치치 않을 수도 있다. 애초에 위와 같은 쓰기 속도 저하도 일반적인 것은 아니었지만.
하스웰부터 지원하는 INVPCID 기능으로 인해 이전 CPU들보다 성능 하락폭이 다소 줄어들었다고 한다. 그렇다고 성능하락이 없는 수준은 아니다. [설명]에 따르면 스카이레이크 이전 세대의 경우 분기 예측을 아예 꺼버린다고 한다. 한마디로 기능 자체를 쓰지 못하는 셈. 구글과 아마존닷컴 측은 멜트다운, 스펙터 버그 패치로 인한 성능 저하 논란은 과장된 이야기이며, 자사의 서버나 클라우드 서비스도 이렇다 할 퍼포먼스 하락은 보이지 않는다고 언급했다.[[79]] 마이크로소프트는 자사의 Azure 서버가 보안 패치 이후 뚜렷한 성능 하락은 보이지 않는다고 밝혔다.[[80]] 애플은 보안 패치 이후, GeekBench 4나 Speedometer, JetStream, ARES-6같은 일반적인 웹 브라우징 벤치마크로 테스트했을 때, macOS와 iOS에서 주목할 만한 성능 하락은 보이지 않는다고 밝혔다.[[81]]
구글은 자사 보안 블로그를 통해 자체 개발한 보안 패치 기술, 레트폴린(Retpoline)을 [[82]] 해당 패치는 스펙터 취약점 중 하나인 분기표적 주입(branch target injection)에 대한 패치이다. 구글에 따르면, 해당 기술이 해킹 위험을 없애면서도 CPU 성능 저하도 막을 수 있다고 한다. 구글은 해당 기술을 업계 파트너사와 공유할 것이며 성능에서 무시할 만한 영향을 준다고 발표했다.
에픽 게임즈에 따르면, 클라우드 서비스 서버에 멜트다운 대응을 위한 업데이트를 한 뒤, 클라우드 서비스 서버의 CPU 사용량이 크게 올라갔다고 한다. [[83]], [[CPU 게이트 에픽게임즈, 보안 패치 후 “서버 CPU 점유율 올랐다”]] 이로 인해, 로그인에 문제가 생기고, 서비스 불안정성이 발생했다고 한다. 에픽 게임즈가 사용하는 클라우드 서비스가 패치됨에 따라 다음주에 예상치 못한 문제가 발생할 수 있으며, 에픽 게임즈는 향후 문제를 막기 위해 클라우드 서비스 제공자와 협력하며 가능한 빠르게 발생하는 문제를 완화시키거나 해결하는 데 총력을 다할 것이라고 밝혔다.
MS의 수석부사장인 테리 마이어슨은 “인텔 보안 결함을 해결하려고 적용한 패치로 인해 특정 서버의 처리 속도가 상당히 느려졌다.”는 말과 함께 “패치 후 성능 저하문제가 인텔이 인정한 것보다 더 심각할 수 있다”는 말과 “일부 PC나 서버의 속도가 현저하게 떨어졌는데 특히 2015년형 PC로 윈도7이나 윈도8을 사용하는 소비자 대부분이 뚜렷한 성능저하를 느낄 것”이라고 지적했다.
해당 사태가 지속적으로 일어나자 [해당 문제를 인정]하였다. 주요 시스템에서 6~7%정도의 하락이 있으며, 경우에 따라 10%이상 하락이 이루어진다고 하였다. 게다가 이 부분은 스카이레이크 이상의 cpu에서 일어나는 부분이라 그 이상 된 구형 cpu의 경우는 하락폭이 더 커진다.
인텔의 공식 벤치에서는 이렇게 되어 있다.
* 8세대 모바일 프로세서 기반 시스템의 경우 종합점수 기준 적게는 1%에서 많게는 10%, 세부점수 기준 최대 14% 하락. * 7세대 모바일 프로세서 기반 시스템의 경우 종합점수 기준 적게는 1%에서 많게는 7%. 세부점수 기준 최대 14% 하락. * 6세대 데스크탑 프로세서 기반 시스템의 경우 종합점수 기준 최대 10%, 세부점수 기준 최대 21% 하락. 경우에 따라 6% 성능 상승.
서버쪽의 경우 [상당한 성능 하락이 이루어졌다.] 테스트 환경은 2소켓 인텔 제온 시스템(스카이레이크)인데 상당히 비싼 cpu이며, 고사양을 자랑하는 수준인데도 불구하고 정수와 부동소수점 처리량, 린팩, 스트림, 자바 테스트에서는 0~2%. 온라인 거래 처리 OLTP 벤치마크는 4% 하락했다. 스토리지 벤치마크는 구성에 따라서 몹시 다양한 결과를 보였는데, 100% 쓰기에선 CPU의 부담이 매우 커졌으며 이 경우엔 18%의 성능 하락했다. 70% 읽기에 30% 쓰기에선 2% 줄어드는데 그쳤으며, 100% 읽기에서는 별 영향이 없었다. 그리고 SPDK (Storage Performance Development Kit) 테스트에서는 다양한 조합의 iSCSI 성능이 25% 정도 하락했다.[* 더 큰 문제는 보통 서버로 사용되는 cpu든은 6세대보다도 더 구형인 경우가 꽤나 많다는 점 이다. 6세대인 스카이레이크만해도 이런데 그 이전 것들은 오죽할까?]
삼성 SDS에서 자체적으로 실시한 결과 데이터센터에 따라서 [60%]라는 경이로운 속도하락을 보여주었다고 한다.
인텔의 스펙터 패치 이후 성능 하락이 없다고 발표한 것이 사실은 해당 패치 기능을 꺼놓고 돌린 것이라 욕을 먹고 있다.
윈도우 10 RS4 빌드에서 스펙터 패치를 적용했을 때 SSD 4K 성능이 반토막난다고 한다. 실제로 성능 저하가 확연히 느껴진다는 사람들도 있다.
패치 자체의 문제
i5 1세대 CPU(린필드)에서 패치 이후 지속적으로 컴퓨터가 강제 종료되는 현상이 일부 사용자에게서 발생한다고 한다. 또 하스웰 (4세대) 칩에서는 패치를 하면 강제 재부팅 현상이 발생한다고 한다.[[84]] PC가 무작위로 꺼졌다가 켜진다는 것이다. 12일 나온 WSJ 기사에 따르면, 인텔은 보안패치의 결함을 인정하고 일부 고객에게 (하스웰 사용자들) 패치를 설치하지 않도록 권고했다. 그러다가 인텔 코어 2 ~ 7세대 내장 그래픽 사용자는 재부팅 현상도 발생되기 시작하였다. [[85]] 그야말로 점입가경
결국 인텔은 패치 배포를 중단했다. [[86]] 이후 2018년 3월에 2 ~ 8세대 cpu를 대상으로 새로운 마이크코드 업데이트가 배포되었다.
한편 일부 구형 AMD 시스템(구형 애슬론에서 문제가 있었다고 한다)에서도 패치 이후 컴퓨터가 부트되지 않는 문제가 발생했다고 한다.[[87]] 이유는 일부 AMD 칩셋이 AMD가 제공한 문서대로 작동하지 않기 때문이었다고(…). MS와 AMD는 일단 이 패치를 AMD 시스템에서 받지 못하게 하였으며 며칠 후 해당 문제를 해결한 패치가 나왔다.
이외에도 메모리 관련 패치다 보니 산업용 임베디드 시스템에서 문제가 많다고 한다. [[88]] 2010년대부터는 공장이라도 랜섬웨어 공격을 당하는 등 보안에서 안전 지대가 아니기 때문에 보안 패치가 필수가 되어가는 상황인데 이런 식으로 문제가 생기면 답이 없다(…). 다만 대부분의 자동화공장 설비는 오프라인된 폐쇄 시스템이긴 하다. (인터넷에 연결이 되어 있지 않아 그 공장 건물, 정확히는 인트라넷 밖에서 접근할 회선 자체가 없다는 것.)
이후 전개
사건 전개도
* 멜트다운 버그의 구조에 대해 잘 모르던 개인 사용자들에게는 대응 패치 이후 성능 저하 여부만 주목받았으나, 사실 멜트다운 버그의 핵심 부분은 보안 취약점이기 때문에 성능 저하는 어디까지나 덤에 가깝고, 보안 문제가 훨씬 더 심각하다. * 인텔 개인 컴퓨터의 성능 저하는 다음과 같다. 게임프레임은 영향없으나 스펙터 유형2를 위한 메인보드 펌웨어 업데이트까지 할경우 SATA방식은 약간의 영향이 있으며, NVMe방식 SSD는 심각하게 떨어진다. NVMe 방식 SSD의 경우 성능이 높을수록 떨어지는 수치가 높으며 CPU가 구형일수록 이 수치는 더 떨어진다. CPU를 많이 쓰는 서버에는 누적 성능 저하가 더 심각하게 영향을 주고 있다. * 인텔의 무성의한 대응이 사태를 더욱 악화시키고 있다. 이 버그도 대응이 무성의하지만, 그 직전에 일어난 인텔 관리 엔진 관련 보안 버그도 굉장히 무성의한 대응으로 일관 중이고, 이 문제도 현재진행형이기 때문. --레노버, DELL, HP 등의 완제품 PC 제조사들: 아이고 두야.-- * 스펙터의 경우에는 AMD도 이 문제에서 완전히 자유로운 것은 아니며, 또한 대다수의 모바일 CPU가 위협에 노출되어 있다. 물론 인텔이 더 심각하다. * CEO 브라이언 크르자니치를 포함한 인텔 전현직 고위 간부들은 2017년 11월부터 12월까지 CEO의 경영권 보장 분의 주식 등을 제외한 본인들이 팔 수 있는 한계 안에서 모두 주식을 매각하였다. 특히 크르자니치는 엔지니어 출신인데 그동안 한 일이 가관이다. R&D 예산 대폭 삭감, 엔지니어 대량 해고, 기존의 상품을 조금씩 바꾸어 비싸게 팔아먹음, 엄청난 CPU 결함을 알고도 신제품 출시, 그리고 결함을 은폐하고 자신이 소유하고 있는 주식중에서 팔 수 있는 수준의 자사 주식은 다 팔아 먹음. 정작 이 사건이 알려지기 전인 2017년 12월 포브스에서 '사내 복지 잘하는 CEO 1위'로 선정되기도 했다. * 인텔은 혼자 죽기 싫어서 '모두 문제가 있다'는 식으로 물타기.[글][이런 분위기.jpg] * 인텔, CPU 보안 결함과 관련해 집단소송 피소.[* [큰코 다치나..인텔에 소비자 줄소송, 애플엔 벌써 26건]] * 구글, 인텔에 수 개월 전부터 이를 통보했으나 인텔 측에서 무시, 심지어 인텔의 CEO인 크르자니치 역시 이를 알고 있었음을 실토. * 구글이 문제있음을 알린 때가 7월인데, 이때에 인텔이 커피레이크를 출시했다. 이건 아무리 봐도 소비자 엿먹이기다. --라이젠 샀다가 8세대 간 사람들 지못미-- * 닌텐도 스위치를 포함한 여러 콘솔 게임기들의 불법 복제 및 보안 체계 붕괴 우려. 특히 닌텐도 스위치는 최근 엔비디아 테그라 칩셋에 의한 보안이 뚫려 PSP의 커펌 문제가 재발할 가능성이 매우 높아져 심각한 문제가 될 수도 있다. 반면 플레이스테이션 4(Pro 포함), 엑스박스 원(X 포함)은 AMD의 CPU를 쓰기 때문에 영향이 적다. 스위치는 구버전 펌웨어에서는 홈브류가 돌아가는 수준이며 몇몇 해킹 그룹이 개발완료 혹은 개발중이며 곧 공개한다며 입을 털고는 있지만 아직까지 보안체계 완전 붕괴 까지는 오지 않았다. * 미국 상원 은행위원회 소속 상원의원 2명은 증권 거래 위원회와 법무부에 인텔 CEO 브라이언 크르자니치가 내부자 거래법을 위반했는지 조사해줄 것을 촉구했다. [[89]] 인텔은 모든 정부 조사와 수사에 협조하겠다고 밝혔다.
프로젝트 제로 게시글에 따르면 각 CPU 벤더들의 반응은 다음과 같다.
* AMD는 홈페이지에 각 취약점의 영향과 해결 방법을 공지하였다.[[90]] * ARM은 해당 취약점에 영향을 받는 칩셋과 해결 방법에 대한 페이지를 공개하였다.[[91]] * 인텔은 답변을 전혀 주지 않았다고 한다(No current statement provided at this time).
상황 초기에 비해 개인 사용자 사이에서의 성능 저하는 잠잠해졌지만, 맨 위에 있는 멜트다운 데모 동영상이 공개되자 보안 결함이 예상보다 훨씬 심각한 상황이었음이 알려졌다. 보안패치가 필수가 된 만큼 CPU의 성능 저하가 적다고 해도, 하나하나의 성능 저하가 누적될 만큼 여러개, 대량의 CPU를 사용하는 서버와, 클라우드 컴퓨팅 회사들이 큰 영향을 받을 것으로 보인다. 마이크로소프트, 구글, 바이두, 드롭박스 등 여러 회사들은 AMD EPYC 시리즈를 이미 여러 서버에 적용 중이며, 이번 보안 문제로 인해 인텔의 보안 관리 능력에 의심을 가진 회사가 늘어나 AMD의 서버 시장 점유율이 높아질 가능성이 있다. 근본적으로는 하드웨어 문제라 현존하는 최선의 해결책은 AMD EPYC 시리즈로 옮기는 것밖에 없다. 물론 스펙터 취약점은 AMD에도 존재하지만, 멜트다운과 스펙터 모두 가지고 있고 패치하면 성능 저하되는 인텔보다는 훨씬 낫다.
현재 인텔의 핵심 인력은 은퇴하거나 퇴사[* 인텔의 엔지니어 [피에노엘]] 혹은 사망한 지[* 인텔의 전 CEO 폴 오텔리니] 오래이고 [조직이 망가졌다는 내부 소식이 있다]([[92]]). 최악의 경우 리콜 후 보상으로 인해 인텔이 엄청난 경영난을 겪을수도 있다. 한 전문가에 [[93]], 리콜 비용이 약 270억 달러 이상, 한화로 약 29조 원 이상이 될 것이라고 한다. 2018년 1월 4일 기사에 의하면 인텔은 멜트다운과 스펙터로 인한 리콜은 없다고 밝혔다.[[94]] 사실 그도 그럴 것이 95년 이후 생산된 대부분의 CPU에 보안 결함이 있는 상황에서 리콜을 한다 해도 보상해 줄 CPU가 없다.
인텔은 이번 이슈로 인해 하루 만에 주가가 7% 가까이 하락하였다. 한편 지난 석달 새에 인텔의 크르자니치 CEO를 포함한 주요 고위층 간부들이 주식을 매도해왔다는 사실이 보도되어 이미 간부들은 이 사실을 미리 알고 주가가 하락하기 전에 손을 턴 것이 아니냐는 의혹이 제기되고 있으며 사실일 경우 이는 모럴해저드, 노블리스 오블리주에 관한 중요한 문제다. [[95]] 때문에 현재 2명의 미국 상원의원이 증권 거래 위원회와 법무부에 인텔 CEO를 조사해줄 것을 촉구하고 있는 상황이다.
또한 이미 구글 측에서 이런 보안 취약성에 대한 연구결과를 인텔 측에 따로 제보하였음에도, 인텔에서는 별다른 조치를 취하지 않았으며, 오히려 말도 하지 않고 8세대를 출시 하여 소비자를 우롱하였으며, 위에 적혀있듯이 CEO를 포함한 임직원들은 해당 소식을 들은 후부터 몇 달동안 주식을 팔아버리기도 했다.
한편 인텔 측에서는 다른 CPU도 문제가 있다고 언급하였는데, 이는 사실이기는 하다. 하지만 스펙터 버그는 앞서 말한 특성상 활용 범위가 제한적이다. 멜트다운 취약점과 스펙터 버그는 엄연히 무게와 양상이 다른 버그임에도 모든 CPU의 동일 문제인 듯한 뉘앙스로 변명한 것은 물타기이다.
대부분의 인텔 CPU가 하드웨어적으로 문제점이 있다는 것이 드러나자 난리가 났으며 위에서 이야기하다시피 보안 패치는 근본적인 해결책이 되지 못한다. 그동안 인텔 CPU를 쓴 기기들은 취약점에 고스란히 노출될 수 밖에 없고, 소프트웨어 패치로 최대한 버티거나 AMD의 ZEN 아키텍처 기반 CPU로 갈아타는 것 외엔 별다른 방법이 없다. 다만 일반인의 경우 NVMe SSD의 성능하락외 다른 성능 하락에 대해 크게 걱정할 부분이 없으나 각종 서버 등 기업용 제품의 경우 문제가 될 수 있다. CPU교체 이외에는 근본적인 해결책이 없어서 매우 난감한 상황.
미국 미국의 정보 기술 연구 및 자문 회사인 가트너의 부회장 네일 맥도널드는 [문제 해결은 재설계밖에 답이 없다]고 이야기를 하였다. 물론 그때까지 CPU 장사를 아예 접었다가는 도산을 피할 수 없으므로, 인텔은 기존 마이크로아키텍처는 그대로 둔 채로 보안 칩만 단 새 프로세서를 전격 출시하여 피해를 최소화하기로 결정했다. [[96]], [[97]] 보호장치를 내장한 것이기 때문에 보드나 CPU쪽에 추가될 것으로 예상되며 이는 근본적인 부분에서 해결을 하기에는 시간이 [4년]이라는 긴 시간이 걸리기 때문에 멜트다운과 같은 가장 큰 보안문제를 해결하기 위한 방법으로 일단 보안 칩을 달아 최악의 상황을 피하기로 결정한 것. 당연하게도 인텔의 이 소식이 들려오자마자 [주가는 상승]하였다.
구글 측에서 밝힌 보안 취약점 보고서에서 AMD는 스펙터 버그에만 해당하는 유형 1, 2의 가능성만을 가지고 있다고 했으며, 유형 3인 멜트다운은 아키텍처가 달라 해당사항이 아니라 했다. [유형 1은 이미 윈도우 업데이트와 리눅스 업데이트로 해결이 된 상태]이며, [유형 2는 자체실험 결과 발견되진 않았다]고 하지만, 돌파될 가능성은 매우 희박해도 존재를 하기 때문에 [업데이트를 통해서 이를 해결]한다고 하며, 곧 있으면 나올 예정이다.
인텔은 자신들이 알게 된 이 멜트다운과 스펙터 관련 보안 문제를 구글, 마이크로소프트 등 고객사들에게 알려줬는데 문제는 해당 기업들 중에 레노버와 알리바바가 있었고 이로인해 중국 공산당 쪽으로 관련 정보가 넘어갔을 가능성이 제기되었다. 이에 반해 미국 국토안보부와 국가안보국(NSA)은 인텔로부터 아무런 연락도 받지 못한 관계로 언론에 보도가 되기 전까지 보안 문제에 대해 알지 못했다고 한다. [기사] [[98]]
다만 인텔이 중국 공산당에 직접 통보한 적은 없다. 비즈니스 관계상 기존 협력업체에 먼저 통보한 것에 불과하고 그 목록에 레노버 등이 끼어있었을 뿐이다. 이 행위 자체는 그다지 특별할 것은 없고 실제로 중국 당국에 직접 통보했다면 일이 지금보다 훨씬 심각해졌을 것이다. 다만 여기서 문제는 중국 공산당이 중국 IT 기업들을 모니터링하면서 영향력을 행사하고 있다는 점, 실제로 이 사건에서도 그런 방식으로 중국 공산당에게 정보가 흘러갔을 가능성이 높다는 점이다. 이 대목이 바로 미국에서 문제삼는 부분이다.
AV-Test에 따르면 1월중 스펙터와 멜트다운 취약점을 이용한 멀웨어 샘플 139개를 바이러스 토탈에서 발견했다고 한다. 일부 샘플에는 불완전한 코드가 들어 있는 것으로 봐서 모든 샘플이 취약점 공격에 성공하진 않았을 것으로 추정된다. [[99]]
2018년 6월 21일 [주범중 하나인 크르자니치 인텔 CEO가 사임을 표명했다.] 사유는 인텔의 관리자급 이상 간부는 내부 교제를 해서는 안된다는 규정이라는데 영 석연치 않게도 과거에 이를 위반한 사실이 최근 밝혀졌다고 한다.
외부 링크
* [그라츠 대학교에서 만든 안내 홈페이지] * [및 패치 내용 설명]
분류:2018년 사건 분류:인텔분류:컴퓨터 보안분류:중앙처리장치분류:오류