CPU 게이트

컴퓨터 공학 용어로 쓰이는 게이트에 대한 내용은 트랜지스터 문서 참고하십시오.

주의. 사건·사고 관련 내용을 설명합니다.

사건 사고 관련 서술 규정을 유의하시기 바랍니다.

1. 개요2. 알려지게 된 과정

2.1. 연구진 공식 Q&A

3. 취약점 상세 정보

3.1. 멜트다운

3.1.1. 커널 값을 읽어내는 프로그램

3.1.1.1. 비전공자를 위한 설명3.1.1.2. 전공자를 위한 간단한 설명3.1.1.3. 전공자를 위한 보다 더 기술적인 설명

3.1.2. AMD CPU에 멜트다운 취약점이 발견되지 않은 이유3.1.3. 차기 인텔 하드웨어의 해결책 예상3.1.4. 운영체제를 통한 임시방편3.1.5. 심각성

3.2. 스펙터3.3. 추후 발견된 취약점

3.3.1. 인텔 AMT 관련 추가 보안 문제3.3.2. 스펙터 프라임 / 멜트다운 프라임3.3.3. 브랜치스코프3.3.4. Spectre-NG 추가 발견3.3.5. L1TF 버그 발견3.3.6. Spoiler 취약점 발견3.3.7. 좀비로드/폴아웃(=MDS) 취약점 발견3.3.8. SWAPGS 취약점 발견3.3.9. NetCAT 보안취약점 발견3.3.10. TSX ATA & JCC 취약점3.3.11. 플런더볼트(Plundervolt) 취약점3.3.12. 캐시아웃(CacheOut) 취약점3.3.13. LVI 취약점

4. 해당 버그에 취약한 하드웨어5. 취약점에 대한 대응

5.1. Intel5.2. AMD5.3. OS5.4. 웹 브라우저, 그 외

6. 사용자가 할 수 있는 대처법

6.1. 취약 여부 확인6.2. 메인보드 펌웨어 업데이트6.3. 윈도우6.4. macOS6.5. 리눅스

7. 사건 여파

7.1. 보안 패치 후 하드웨어 성능 하락7.2. 패치 자체의 문제

8. 이후 전개9. 기타10. 외부 링크

1. 개요

대부분의 현대 x86 CPU와 IBM의 POWER CPU, 그리고 ARM 일부 아키텍처에서 몇 가지 중대한 보안 취약점이 발견된 사건. 2018년 1월 3일 구글에서 최초로 발표했다. 취약점 원인에 따라 두 종류로 멜트다운, 스펙터라는 명칭이 붙었다. 하트블리드 이후 터진 IT계 최대의 보안 이슈이자 뜨거운 감자로, 대상 CPU를 생산했던 여러 CPU 제조업체, 특히 인텔에게는 큰 위기를 불러일으킨 이슈다.

구글 프로젝트 제로의 얀 호른 수석연구원과 오스트리아 그라츠 공과대학, 그리고 업계 보안전문가들이 처음 발견했다. 이와는 별도로 2017년 말에 인텔 관리 엔진 관련 보안 버그가 발견되었다. 이것도 보안 시스템을 무시하고 시스템을 망가뜨릴 수 있는 치명적인 버그였는데 불과 몇 개월만에 훨씬 위험한 버그가 잇달아 터져서 IT업계 전체에 큰 일이 발생했다. 흔한 보안 이슈가 아니라 게이트 소리를 듣는 대사건이다. 특히 인텔 CPU의 경우, 2018년 당시 현역으로 사용 가능했던 대부분의 제품[1]이 버그의 위험에 노출되어 50년 역사의 인텔의 창업 이래 최악의 위기라는 우려도 나왔다. 또한 버그 보완 패치의 부작용으로 시스템 콜 성능이 심각하게 저하되기도 했고 세대가 오래 되었을수록 하락폭이 더 컸다. 인텔은 세대별 보안 버그에 대응하는 방법을 표로 제공하고 있다.

2. 알려지게 된 과정

원래 이 버그는 2017년 4월경 구글 산하 프로젝트 제로의 사이버 보안 연구원 Jann Horn이 자신이 설계한 프로그램이 제대로 작동할지 확인하기 위해 인텔 CPU의 설명서를 보다가 발견하여 #, 동년 6월경 마이크로소프트와 리눅스 개발진 등에게 알려 보안 패치 등 필요한 조치를 취한 뒤 2018년 1월 9일 공개할 예정이었다. 이 조치는 제로 데이 공격 방지를 위해 어마어마한 엠바고가 걸린 상태에서 비밀리에 진행되었는데, 리눅스 개발자들이 커널 핵심부를 건드려야 해서 작업량이 많은 데다 그다지 필요 없을 기능들을 추가하기 위해 허겁지겁 일하고, CC로 인텔, 구글, 아마존의 관계자들의 메일 주소가 달려 있고, 코드 주석엔 무언가 검열되어 있고, 인텔 CPU가 위험하다는 플래그가 있는 등으로 리눅스 패치 커밋을 지켜보던 사람들이 수상한 낌새를 눈치채, 2018년 새해 즈음에 '정확히는 모르겠지만 인텔 CPU에 심각한 버그가 있다'는 사실이 개발자들 사이에 알려지게 된다. 이후 이 사실이 레딧, 트위터 등의 커뮤니티로 빠르게 퍼져나가자 구글에서는 작업 마무리 단계에서 예정보다 빠른 1월 3일에 이 내용을 발표했다.

레딧에 처음 알려진 버그의 내용은 다음과 같았다. 번역 출처, 원문 출처.

* 해당 버그는 인텔의 몇 세대에 걸친 버그입니다. 인텔 한정으로, AMD는 영향 없는 것으로 보입니다. (다만 현재 커널 패치에서는 AMD를 수정사항에서 제외하는 항목이 적용되지 않은 상태. 즉 현 커널 패치에서는 같이 성능이 떨어질 것으로 예상됨.)
* 해당 버그는 리눅스뿐만 아니라 Windows, macOS 모두에 영향을 줍니다.
* 해당 버그는 엠바고로 인해 아직 전모가 밝혀지지는 않았습니다.
* 해당 버그는 인텔 CPU의 버그로 인해 커널 메모리 정보가 유저 공간으로 유출될 수 있는 결함입니다.
* 해당 버그로 인해 크게 공개되지는 않았지만 데이터 센터/클라우드 업체 등에서는 상당한 물밑작업이 진행되었을 것으로 예상됩니다.
* 해당 버그의 수정으로 인해 발생하는 성능 손실은 각 OS와 기타에 따라 다르지만 대략 5~30% 정도로 알려져 있습니다.
* 해당 버그에 대응하는 리눅스 커널 패치는 이미 릴리즈 되었습니다.
* PCID 기능이 적용된 신형 인텔 CPU에서는 해당 버그의 커널 패치로 인한 성능 저하가 완화되는 것으로 알려져 있습니다.

* 해당 버그에 대응하는 리눅스 커널 패치를 적용하고 테스트 해 보니….
1. 파일시스템 I/O쪽은 성능이 반토막이 납니다.
1. 컴파일러 벤치마크 중 initial setup 항목에서 15% 정도 성능이 저하됩니다.
1. 커널 컴파일, 인코딩 등은 큰 영향이 없는 것으로 나타납니다.
1. SQL 같은 데이터베이스 관련 벤치에서도 15% 정도 성능이 저하됩니다.
1. 데이터 스트럭처 서버에서 6% 정도 깨집니다.
1. 게임은 영향이 거의 없습니다.[2]

작업별 테스트 결과, 게임 테스트 결과.

위 내용대로라면 현재의 모든 인텔 코어 i 시리즈 및 i 시리즈 기반 제온이 해당 보안 버그에 노출되어 있으며, 이를 운영체제에서 논리적으로 수정할 경우 최대 30%까지도 성능 하락이 생길 수 있다고 한다. 패치 전후의 시스템 콜의 자체의 성능만 테스트한 결과 최대 70% 이상 성능이 떨어졌다는 테스트도 있다. 물론 실제 프로그램에서는 다른 작업을 같이 수행하기 때문에 이 정도로 성능 하락이 일어날 가능성은 없지만, 프로그램의 작동 방식 및 상황에 따라서 매우 큰 폭의 성능 하락이 일어날 가능성은 열려 있다.

구글이나 아마존 등의 대형 IT 업체들 역시 이 문제를 피해가기 어려운 상황이라고 한다.

밝혀진 바로는 기업/서버/전문가용 기준으로 1995년 11월에 발매된 펜티엄 프로부터, 일반 사용자용 기준으로 1997년 5월에 발매된 펜티엄 2부터 거의 모든 인텔 CPU들이 해당된다. 즉, 사실상 P6 마이크로아키텍처 기반의 모든 프로세서들이 해당된다. 그리고 여지껏 새로운 아키텍처[3]라고 발표해 왔던 것들이 사실은 죄다 저 P6 마이크로아키텍처 짜깁기에 불과했다는 사실이 알려지면서....

2.1. 연구진 공식 Q&A

이하 문답은 이 버그를 발견한 연구진이 게시한 짧은 Q&A의 일부분을 번역한 것이다. 원문은 이곳에서 볼 수 있다.

제가 이 버그의 영향을 받을까요?

아주 확실히 그렇습니다.

누군가가 멜트다운이나 스펙터를 써서 저를 공격[4]했는지 알 수 있나요?

아마도 못할 겁니다. 이 공격은 기존 방식의 로그 파일에 흔적을 남기지 않습니다.

제 백신이 이 공격을 감지하거나 방어할 수 있나요?

이론적으로는 가능하지만, 현실적으로는 어렵습니다. 일반적인 악성코드와 달리 멜트다운과 스펙터는 정상적인 프로그램과 구별하기가 어렵습니다. 다만 해당 공격 방식을 사용하는 악성코드가 발견된다면 그 바이너리와 비교대조하여 탐지할 수 있습니다.

어떤 것이 유출될까요?

만약 당신의 시스템이 영향을 받는다면, 우리의 개념 실증 코드[5]로 당신 컴퓨터의 메모리의 내용을 읽을 수 있습니다. 여기에는 시스템에 저장된 암호와 중요한 데이터가 포함되어 있을 수 있죠.

멜트다운이나 스펙터가 이미 다른 곳에서 악용되었던 적이 있을까요?

저희도 모릅니다.

3. 취약점 상세 정보


Meltdown 멜트다운 ^{CVE-2017-5754}	Spectre 스펙터 [6] ^{CVE-2017-5715} ^{CVE-2017-5753}
그라츠 공과대학이 개설한 안내 사이트

관련 정보

현대 CPU에서 사용하는 최적화 기법인 비순차적 실행(out-of-order execution)과 추측 실행(speculative execution)의 결과로 나타나는 프로세서의 상태 변화에 대한 부채널 공격 [7]이다. 세 가지 유형(Variant)이 존재한다.

유형 1: 경계검사 우회 (bounds check bypass, CVE-2017-5753)
유형 2: 분기표적 주입 (branch target injection, CVE-2017-5715)
유형 3: 불량데이터캐시 적재 (rogue data cache load, CVE-2017-5754)

유형 1과 2에 스펙터, 유형 3에 멜트다운이라는 이름이 붙었다. 간단히 요약하자면, '멜트다운'은 유저 프로그램이 운영체제 권한 영역을 훔쳐보는 취약점이고, '스펙터'는 한 유저 프로그램이 다른 유저 프로그램 메모리를 훔쳐보는 취약점이다.

CPU 명령어는 사용자에게는 순차적으로 실행되는 것처럼 보이지만, 내부적으로는 최적화를 위해 뒤쪽 명령어를 미리 실행한다든지 조건에 따라 분기되는 부분에서 가정을 세워 실행하는 등의 최적화를 수행한다. 이렇게 미리 계산한 값이 맞을 경우 해당 값을 실제로 적용해 사용자에게 보여주고, 틀리다면 해당 계산을 파기하는데 두 가지 취약점은 실제로는 실행되지 않는 파기된 계산에서 정보를 누출하는 공격을 수행한다.

이름에서 볼 수 있듯, 멜트다운이 훨씬 더 심각한 결함이다. 멜트다운이라는 이름 자체가 운영체제의 보안 자체가 철저하게 박살난다 해서 붙은 것이다. 스펙터는 이보단 덜 심각하고 구현하기도 어렵지만, 반대로 막는 것도 어렵다는 유령 같은 특징과 추측 실행(speculative execution)의 어감을 살려 스펙터라는 이름이 붙었다. 현재, 멜트다운은 거의 대부분의 인텔 프로세서와 ARM Cortex-A시리즈 기종[8]에서만 발생한다고 알려져 있다. 하지만 스펙터는 여러 명령어를 동시에 실행하는 최적화가 적용된 거의 대부분의 현대 프로세서에 적용되는 취약점이다.[원문1]

더 요약하자면:

1) 멜트다운과 스펙터, 총 2가지의 결함을 통한 3+1가지 공격코드(유형 1, 2, 3, 3a)가 존재함.
1-2) 유형 1,2가 스펙터이고, 3,3a가 멜트다운
2) 멜트다운과 스펙터 취약점 중 더 심각한 것은 전자, 해당 결함은 인텔 CPU(유형 3)와 일부 ARM Cortex 제품군(유형 3a)에서만 발생.
3) 스펙터 취약점은 인텔, AMD, ARM 프로세서에서 발견.
4) 업데이트는 2가지 버그 다 수정하는데, 멜트다운 취약점 해결 과정에서 성능저하가 크게 발생.

자세한 내용은 Google Project Zero 블로그(영문) 또는 공식 홈페이지에서 취약점 보고서 파일을 다운로드하여 알 수 있다.

3.1. 멜트다운

멜트다운 데모. 메모리에 입력되는 비밀번호가 CPU에 정보 입력 즉시 노출되고 있다. 해당 영상이 나오기 전엔 성능저하 때문에 업데이트를 고민하는 사람이 많았지만 시연 영상이 뜨자마자 대부분 태세전환했을 정도로 심각한 상황임을 보여주고 있다. 원본

원리 일부 요약
스펙터 멜트다운 원리 요약

주의: 인텔만 취약하다고 밝혀진 시점에서 쓰여진 터라 인텔 위주로만 분석해 놨다. 그러나 이후 ARM 기반 프로세서를 쓰는 애플 기기들과 닌텐도 스위치, IBM의 일부 POWER CPU 등도 취약한 것으로 밝혀졌다. 또한 2018년 11월에 인텔뿐만 아니라 최신 AMD CPU에도 적용되는 새로운 멜트다운 변종 취약점(Meltdown-BR)이 발견되었다. 다만 이번에 발견된 Meltdown-PK와 Meltdown-BR은 커널 메모리 영역에 접근하지 못하므로 최초의 멜트다운보다는 심각성이 약간 떨어지는 편이다.

멜트다운을 설명하기 위해서 CPU의 아키텍처와 마이크로아키텍처 두 가지에서 최소한의 정보를 서술하겠다. 참고로 CPU의 아키텍처는 사용자(혹은 운영체제)가 기대하는 CPU의 동작 방식이고, 마이크로아키텍처는 이를 실현하기 위한 구체적인 전략이라고 보면 된다. CPU 아키텍처와 마이크로아키텍처에 대한 설명은 CPU/구조와 원리 문서 참고.

3.1.1. 커널 값을 읽어내는 프로그램

위에 서술되어 있듯 이 프로그램은 컴퓨터공학, 그중에서도 특히 컴퓨터 구조에 대한 전공 지식을 이용한다. 컴퓨터공학과에서도 학부 저학년용 아키텍처 수업은 이 부분을 다루지 않고 학부 고학년 수업에서 슈퍼스칼라, 비순차적 명령어 처리, 캐시 등의 개념을 본격적으로 다루는 경우가 많기 때문에 전공자라 해도 이해하려면 꽤 고민을 해야 하니 읽으면서 좌절할 필요가 없다.

따라서 최소한의 내용만을 설명하는 부분과 전공자를 위해 전문용어와 약간의 기법이 추가된 설명 두 가지를 첨부한다.

3.1.1.1. 비전공자를 위한 설명

본 문단에서는 기술적인 사항은 최대한 배제하고, 정보 탈취 알고리즘의 핵심 아이디어를 비유적으로 설명하는 데 중점을 둔다. 아무것도 모르는 호텔 프론트 직원이 유도신문에 놀아나는 과정이 핵심이다.

해외 순방 중인 대통령을 암살하려는 범죄조직이 있다고 하자. 이 조직은 대통령이 어느 호텔의 A동에 묵는다는 것까지는 알아냈다. 그러나, 몇 호실에 있는지는 알아내지 못했다. 여기서는 A동 202호라고 하자. 대통령 관련 정보는 당연히 1급도 아닌 극비사항이므로 호텔 프론트에는 "A동 관련 질문은 일절 답변하지 말라"는 엄명이 내려와 있다. 따라서 "대통령이 A동 몇 호실에 묵고 있나요?"라고 물어봐도 당연히 "대답해 드릴 수 없습니다."라는 답변만 돌아올 뿐이다. 여기서 조직원은 잔머리를 굴려 프론트 직원의 노하우를 역이용하기로 한다. 프론트 직원은 다음과 같이 일을 처리한다고 알려져 있다.

1. 특정 호실에 대한 문의가 자주 들어오면 직원은 그 방을 시스템에서 자꾸 검색하는 수고를 덜기 위해 해당 방의 정보를 메모지에 적어 놓는다.
2. 메모지에 적어놓은 방의 정보는 검색하지 않고 메모지를 참고해 다른 방에 비해 훨씬 빠르게 대답해준다.
3. 메모지에 뭐라고 적혀있는지 직접 묻는 질문에는 대답하지 않는다.

작전 1단계. 우선 질문을 다음과 같이 바꾼다.

"B동 호텔방 중 A동의 대통령이 묵는 호실과 같은 호실이 비어있나요?"

A동 관련 질문이 들어갔기 때문에 직원은 여전히 "대답해 드릴 수 없습니다."라고만 대답할 뿐이다. 그런데 상기했듯 프론트 직원은 특정 방에 대한 문의가 많이 들어온다 싶으면 호텔 시스템을 계속 뒤져보는 번거로움을 덜기 위해 해당 방의 정보를 메모지에 적어 놓는 습관이 있다. 이제 저 질문을 계속 반복해서 직원의 귀차니즘을 자극해 보자. 그러면 직원은 계속 "대답해 드릴 수 없습니다."라고 대답은 하면서도 메모지에다가는 문제의 "B동 호텔방 중 A동의 대통령이 묵는 호실과 같은 호실", 즉 B동 202호의 정보를 적어 놓을 것이다.

직원의 귀차니즘을 충분히 자극했다 싶으면 작전 2단계로 간다. 작전의 목표는 메모지에 적힌 호실이 어디인지 알아내는 것. 다만 상기했듯 메모지의 내용을 직접 묻는 질문에는 여전히 답변을 거부한다. 하지만 간접적으로 알아낼 방법은 있다. 바로 "2. 메모지에 적어놓은 방의 정보는 검색하지 않고 메모지를 참고해 다른 방에 비해 훨씬 빠르게 대답해준다."를 이용하는 것. 이를 위해 "A동"이라는 말은 싹 빼고 B동에 있는 모든 방에 대해 직원에게 무작위로 캐묻는다. 즉,

"B동 408호 비어 있나요?"
"B동 105호 비어 있나요?"
"B동 803호 비어 있나요?"
...

이런 식. 방의 정보를 순서대로가 아닌 무작위로 캐묻는 이유는, 순서대로 물어보면 규칙을 예측한 프론트 직원이 물어보는 방 정보의 뒷방 정보를 메모지에 미리미리 적어놓아서 빨리 대답해버리기 때문에 귀차니즘을 자극한 게 무용지물이 될 수 있기 때문이다.

A동 관련 질문은 일절 답변하지 말라는 엄명이 내려와 있지만, B동에 대해서는 특별한 지침이 내려오지 않았기 때문에 직원은 모두 순순히 대답을 해 줄 것이며, 물어볼 때마다 아무것도 모르는 프론트 직원은 호텔 시스템을 검색하기 위해 "잠시만요..." 하며 뜸을 들일 것이다. 하지만 문제의 "B동 호텔방 중 A동의 대통령이 묵는 호실과 같은 호실", 즉 B동 202호는 프론트 직원이 이미 메모지에 적어 놓아서, 호텔 시스템을 검색할 필요 없이 뜸을 들이지 않고 바로 대답해줄 수 있다. 그리고 조직원은 이로부터 프론트 직원이 메모지에 써놓은 호실이 B동 202호임을 알 수 있게 되는 것이다. 여기서 B동을 A동으로만 바꾸면 거기에 대통령이 있다는 것을 알 수 있다. 일을 효율적으로 하기 위한 프론트 직원의 노하우가 여기서는 오히려 기밀정보를 유출시켜 대통령을 위험에 빠뜨리는 결정적인 계기로 작용하는 것이다.

3.1.1.2. 전공자를 위한 간단한 설명

설명을 위해 CPU의 정보 처리 방식에 대한 최소한의 지식이 필요하다.

1. CPU 안에는 '레지스터'라는 것이 있다. CPU는 일을 할 때 임시로 숫자를 여기에 적어둔다.
2. 각종 프로그램들은 RAM에 자신이 필요한 정보를 적어둔다.
3. 캐시는 RAM에 비해서 매우 빠르게 정보를 넣었다 뺐다 할 수 있다.

RAM에는 여러 칸이 있으며 프로그램은 각 칸의 번호를 바탕으로 RAM에 숫자를 적어넣거나 읽어온다. 호텔을 생각하면 된다. 1번 방에 철수가, 2번 방에 영희가, 3번 방에 민수가 있다. 2번 방에 누가 있는지 알고 싶으면 호텔 데스크에 '2번 방, 누구?' 이렇게 질문하면 데스크는 '영희'라고 답할 것이다. 3번방의 민수를 퇴실시키고 싶다면 '3번 방, 퇴실' 이라고 데스크에 명령하면 된다. 대략 이런 방식으로 프로그램은 RAM에다가 숫자를 저장하거나 읽어내기 위해 CPU에 명령을 내린다. 다만, 이때 RAM은 너무 느리기에 중간에 더 빠른 캐시 메모리라는 임시저장소를 둔다.

당신이 키보드로 무엇을 입력했는지 훔쳐내려는 해커가 있다고 생각해보자. 키보드로 무엇을 입력했는지 알아내면 은행 거래 비밀번호 등 중요한 정보를 탈취해낼 수 있다. 해커의 목적이 키보드 입력값의 탈취라는 전제하에 다음의 사항을 생각해 보자.

컴퓨터는 모든 것을 숫자로 처리한다. 가령 ASCII코드를 전제할 때 컴퓨터는 'a'라는 문자를 97로 이해하고 'b'라는 문자를 98로 이해한다. 우리가 키보드로 'a'를 칠 때, 컴퓨터는 메모리의 100번째 방에 숫자 97을 적어넣는다고 치자. 원칙적으로는 OS의 핵심부분인 커널 이외에는 메모리의 100번 방에 무슨 내용이 들어가 있는지 아무도 알 수 없다. 만약 해커가 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는 해커가 시킨 일을 다 한다. 단지 보여주지 않을 뿐이다. 예전까지는 해커한테 보여주지만 않으면 괜찮다고 생각했기 때문에 이런 방식이 사용되었다.[10] 'CPU가 일을 다 하고 보여주지만 않으니, CPU가 일한 흔적을 찾아 100번 방의 숫자를 알아내자'라는 것이 멜트다운 버그의 핵심 아이디어이다.

해커는 앞서 간단히 언급한 캐시를 이용한다(캐시는 램보다 속도가 훨씬 빠른 메모리이다.). CPU가 RAM의 1097번 방에 있는 정보를 꺼낼 때, 1097번 방의 정보는 자동으로 캐시에 기록된다. RAM에 있는 정보를 캐시로 베껴 써 두면 나중에 다시 볼 때 이를 빠르게 볼 수 있기 때문이다.[11] CPU는 해커에게 RAM에서 일껏 1097번 방의 자료를 꺼내오고는 해커에게 보여주지는 않는다. 하지만 어쨌든 1097번 방의 자료를 꺼내왔기에 1097번 방의 정보는 캐시에 들어가 있다. CPU가 RAM을 읽으면 무조건 이 정보는 캐시에 기록되기 때문이다.

이제 해커는 RAM의 1000번 방부터 하나씩 방을 검색하기 시작한다. 1000번 이후의 모든 방들은 캐시에 없기 때문에, 램에서 읽어와야 하므로 읽는 데 시간이 꽤 오래 걸린다. 하지만 1097번 방은 캐시에 있기 때문에, 읽는 데 시간이 적게 걸린다. 해커는 RAM의 1000번 방 이후의 방을 읽을 때마다 읽는 데 걸린 시간을 측정한다. 1097번 방을 읽을 때 시간이 적게 걸리는 것을 잡아내면, 해커는 CPU가 나한테 보여주지는 않았지만, 실제로는 1097번 방을 읽었다는 것을 알게 된다. 이를 근거로 al에 원래는 97이 들어가야 했다는 것을 알 수 있고 우리가 키보드로 'a'를 쳤다는 것을 알 수 있다.

3.1.1.3. 전공자를 위한 보다 더 기술적인 설명

기술적으로 완벽한 설명을 하기 위해서는 시스템의 비트 상황이나 캐시구조 등 하드웨어의 세부사항까지 이해해야 한다. 다만 진짜 자세히 설명한다면 문서 하나로는 다 끝나지 않을 정도로 방대한 내용이 되므로 여기에서는 대략적인 개요만을 설명한다. 캐시와 타입캐스팅을 어떻게 활용하는지 확인하는 용도로 사용하면 적절하며 그 이상으로 정확하지는 않다. 이 설명은 OS와 메모리 구조, CPU 파이프라인에 대한 전공지식이 있다는 것을 전제로 한다.

공격 프로그램은 커널의 특정 메모리 주소를 읽기 위해 다음의 변수 및 배열을 설정한다.

1. ka: 값을 읽어올 커널의 메모리 주소.
2. ua1: L1 캐시 크기만큼의 배열
3. ua2: 256 크기만큼의 배열.[12]

코드의 실행순서는 다음과 같다.
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 하지 않을 뿐이다.[13]
넷째. 컴퓨터에서 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이 들어있다는 것을 알 수 있다.[14]
일곱째. E에서 아무 것도 하지 않는 명령어를 적당히 깔아두는 이유는 F가 실행취소되거나 재시도 되는 것을 막기 위한 의도적인 파이프라인 버블이다.

결국 핵심은 조건 분기나 예외 발생 등의 명령어를 처리할 때 파이프라인의 실행 단계에 가야 그 다음에 들어올 명령어가 틀렸는지 알 수 있다는 파이프라인 구조의 단점을 메우기 위한 대책들이 메모리 계층 등 CPU 연산 자체와 직접 상관 없는 부분에 흔적을 남긴다는 것이다. 멜트다운-스펙터 취약점 이후 추가로 발견된 취약점들도 일부 예외를 제외하면 이런 유형에 해당한다. 하이퍼스레딩이 문제가 되는 것도 두 개의 논리 스레드가 하나의 물리 코어를 공유하기 때문에 한 스레드의 연산 결과를 코어를 공유 중인 다른 논리 스레드가 훔쳐볼 수 있다는 것에 기인한다.

3.1.2. AMD CPU에 멜트다운 취약점이 발견되지 않은 이유

이 사달이 난 이유는 D단계가 잘못된 것을 꽤 일찍 알았는데도 실행 취소가 시작된 시점이 완료(Commit) 단계여서 이미 뒤의 명령어들이 실행되어 버렸기 때문이다. AMD는 D단계와 같은 보호 비트 위반을 발견하는 대로 실행 취소를 시작했거나, 보호 비트 위반으로 읽어낸 eax와 같은 값을 읽는 명령어들은 송출(Issue) 단계를 지나지 못하게 막았을 것이다.

다만 AMD 측이 해당 보안 이슈를 알아서 막았다기보다는, 같은 명령어 집합을 인텔과는 다르게 마이크로아키텍처를 설계하여 이런 착오를 범하지 않았다. 일단 CPU 아키텍트 인재 풀이 그리 크지도 않고 회사도 생각보다 자주 옮겨 다닌다. 그러므로 불과 몇 년 전까지는 아무도 이 문제를 몰랐을 가능성이 매우 높다. 인텔의 전(前) CPU 아키텍트 프랑수아 피에노엘은 "이번 버그는 컴퓨터 과학의 새로운 발견이며, 발견되기 전에 몰랐다고 해서 과학자들을 비난할 수 없다."라고 트위터에 글을 올렸다.

왜 두 가지 방식으로 갈렸는지는 다음과 같이 추측해 볼 수 있다. 먼저 AMD의 빠른 예외 처리 방식을 쓰면, 파이프라인 안에서 적절한 취소 시그널을 보내는 로직이 복잡해지겠지만 쓸데없는 명령어에 허비하는 에너지를 줄일 수가 있다. 반면에 인텔 방식은 쓸데없는 명령어에 허비하는 에너지가 늘겠지만 예외 처리의 로직이 단순화되어 평상시의 에너지 효율이 증가하고 그 밖의 TSX와 같은 더 복잡한 기술의 도입이 쉬워진다. 즉, 보안 취약점만 빼고 보면 딱히 우위에 있는 게 아니라는 것. 하지만 보안은 컴퓨터에게 있어서 생명과 같다. 네트워크에 아예 연결하지 않거나 아예 외부로 연결되지 않는 내부 네트워크 전용으로 굴리면 몰라도 외부 네트워크에 연결되는 게 기본인 이상, 아무리 성능이 효율적으로 나온다고 해도 보안 문제가 있으면 소용이 없다. 사실, 내부 전용으로 굴리는 네트워크라 하더라도 사보타주가 존재할 가능성을 완전히 배제할 수만은 없기 때문에 무조건 안전하다고 생각하는 것은 절대 금물이다.

3.1.3. 차기 인텔 하드웨어의 해결책 예상

AMD와 마찬가지로 보호 비트 위반과 같은 예외(exception)를 처리하기 시작하는 시기를 완료(Commit) 단계가 아닌 실행(Execute) 단계쯤으로 대폭 앞당길 가능성이 높다.

추측 실행(Speculative execution)을 제거하면 어떻겠냐고 하는 사람도 있는데, 사실상 불가능한 방법이다. 이유는 다음과 같다.

추측 실행 없이 중단(interrupt)을 지원하려면 가끔 일어나는 중단(interrupt) 처리를 위해 끔찍한 성능 감소를 감수해야 한다. 중단은 외부 장치의 핸들링이나 내부 명령어의 예외처리를 운영체제가 미리 등록한 별도의 코드로 실행할 수 있게 하는 필수적인 기능이다. 문제는 중단 발생이 대부분 명령어에서 일어날 수 있다는 것이다. 결과적으로 대부분 명령어는 잠재적인 분기 명령어가 되며, 따라서 추측 실행 없이는 명령어 대다수가 실행 단계가 완수해서 중단 발생 여부를 확인하고 나서야 다음에 호출(Fetch)할 명령어를 알려줄 수 있게 된다. 이는 결코 받아들일 수 없는 사태이므로, 중단은 매우 드물게 일어나는 점에 착안해 중단은 항상 일어나지 않는다고 예측해도 거진 다 맞게 되고 성능도 대폭 향상된다. 한 마디로 잘 일어나지도 않을 일을 확인한다고 전 공장이 매번 올스톱하는 것과 같다. 그럴 바에는 그냥 공장을 계속 돌리다가 문제 생긴 제품을 폐기하는 것이 이득이다.
분기 예측(branch prediction)은 안 쓰면 손해가 크다.

분기 예측은 분기(branch)명령어가 "파이프라인이 호출(Fetch) 단계에서 자꾸 쉬게 만드는 문제"를 해결하기 위해 도입된 것이다. 파이프라인을 안 쓰면 지독한 성능저하를 경험한다. 요새도 산업용으로 근근히 POS에서 보이는 1~3세대 아톰 CPU들과 잔존하는 486호환 CPU들은 분기예측이 없다.
각종 추측 실행 기능의 제거가 빈번한 저전력 CPU도, 프로그램이 대부분의 시간을 반복문에서 보내는 특성상 분기 예측이 맞을 확률은 매우 높은 편이다. 에너지적인 관점에서 아주 간단한 분기 예측이라도 하면 전력을 약간 더 써서 성능을 대폭 올리니 결과적으로 에너지 효율적이게 된다.
비순차적 명령어 처리(OoOE)를 버린 저전력 CPU는 명령어의 실행 취소가 매우 간단하여, 분기 예측 실패에 대한 대가마저도 훨씬 적다.

비순차적 명령어 처리의 경우 현재도 저전력 CPU에서는 안 쓰기도 하므로 분기 예측과 달리 버린다는 옵션이 있긴 하지만, 고성능 CPU 시장에서는 비순차적 명령어 처리로 인한 성능 향상이 상당하다. 이걸 걷어내면 아톰이나 J 시리즈 계열 정도의 성능밖엔 안 나올 가능성이 높다. 물론 그런 제품들은 15W 이하로 동작하므로 실제 데스크톱용으로 90W쯤으로 TDP를 올려 설계하면 성능 향상이 되겠지만, 그렇다 해도 넷버스트 아키텍처의 펜티엄 4, 펜티엄 D 시절 수준의 전성비가 다시 강림할 가능성이 크다. 물론 문제 해결이 생각보다 어려울 경우에는 보안을 포기하느니 전성비를 포기하는 게 훨씬 나으므로, 그렇게 되면 과거 AMD 불도저나 넷버스트 시절처럼 펜티엄과 셀러론이 95W TDP, 코어 i 시리즈는 135W~225W의 소모 전력을 자랑하게 될 것이다. 참고로 AMD는 불도저, 비쉐라 시절까지도 후달리는 클럭당 성능비( IPC)를 억지로 클럭빨로 해결했기 때문에 웬만한 시퓨들이 95~135W였으며, 터보 클럭 5GHz짜리 225W CPU가 있었다. 결국에 OoOE를 버리기로 한다면 아마도 그렇게 될 듯.

3.1.4. 운영체제를 통한 임시방편

CPU 아키텍처 설명 맨 마지막에도 서술된, 유저 프로세스의 가상 메모리의 특정 주소가 커널 데이터를 담는 최신 커널의 신속한 최적화를 멜트다운 버그를 해결하기 위해 없애 버렸다. 이는 임시방편이다. 즉 보호 비트에 의존해서 유저와 커널의 가상 메모리 공간을 합치던 최적화를 포기하고, 다시 두 메모리 공간을 분리해 버린 것이다. 따라서 유저 프로세스에서 커널 기능을 사용할 때마다 페이지 테이블이 교체되는 작업이 추가로 필요해진다. 결과적으로 구체적인 정도의 차이는 있을지언정, 파일을 읽고 쓰거나 네트워크 송수신을 하는 소위 입력/출력(Input/Output, I/O)을 포함해 커널의 메모리 권한으로만 가능한 작업들의 성능이 하락할 수밖에 없다.

3.1.5. 심각성

커널 권한을 가지고 있지 않은 프로그램에서 커널 메모리를 읽을 수 있다는 것은 현대 컴퓨터의 보안 체계를 뒤흔들 수 있는 위험성을 가지고 있다. 다만 멜트다운 취약점 자체만으로는 커널 메모리의 읽기만 가능하고 쓰기는 불가능하므로, 직접 시스템에 파괴적인 행동을 하거나 랜섬웨어 등 악성코드를 심는 것은 불가능하다. 이 취약점을 이용하기 위해서는 어떤 식으로든 다른 방법을 통해 먼저 시스템에서 공격하는 코드를 알아내야 한다. 그러니까, 알려진 바 대로 갑자기 전세계 대부분 컴퓨터의 보안이 무력화 되는 것은 아니다. 그리고 한가지 더 알아야 할 것은 취약점이 있긴 해도 이용을 하기가 너무 어렵다는 것이다, 커널 메모리를 읽을 수 있어도 정확한 시간에 정확한 곳을 읽어야 의미가 있는 건데, 실험 환경이 아닌 일반적인 컴퓨터에서 그 정확한 곳을 알려면 본문에 설명된 멜트다운/스펙터의 원리를 꿰뚫는 것보다 훨씬 더 복잡한 지식이 필요하다. 그래서 분명 전세계 대부분의 컴퓨터에 있는 취약점이지만, 2023년 현재까지도 단순히 시연 목적이 아닌 실제 상황에서 의미가 있는 해킹을 성공했다는 보고는 한 건도 없다.

하지만 그렇다 해도 이 보안 문제점은 평소엔 기를 쓰고 보려고 해도 볼 수 없었던 커널 메모리의 내용을 쉽게 들여다 볼 수 있는 치명적인 결함이 명백하며, 읽기 전용의 한계도 물리적 보안을 뚫고 별도의 해킹 프로그램들과 연계하면 당연히 커널 메모리를 읽는다는 점에서 위협적이라는 것은 명백한 사실임이 분명하다. 현대의 보안 프로토콜은 비대칭키 기반 암호화 알고리즘을 사용하는데 이 암호화 알고리즘이 작동할 때에는 CPU에 특징적인 어떤 '흔적'이 발생한다. 이 흔적을 추적하여 멜트다운 공격을 시도하면 암호화에 사용되는 개인키를 유출할 수 있고 개인키가 유출된 시스템은 그 이후의 모든 통신을 수신, 변조, 사칭할 수 있다.

또 다른 문제는 멜트다운 취약점을 이용할 때는 특별한 징조를 보이거나 증거를 남기지 않는다는 것이다. 일반적으로 보안 취약성을 악용하는 코드는 이용하는 명령 자체가 시스템에 기록이 남기 쉬운 명령을 이용하거나 권한을 얻는 과정 등 기존에 시스템에서 이용하던 동작을 이용하던 과정에서 취약점을 이용하고 이 과정에서 흔적을 남기거나, 또는 특정 보안 취약성에 맞게 작동하는 과정에서 코드 및 명령어 자체가 특정한 패턴을 보이는 경우가 많다. 하지만 멜트다운 취약점은 훨씬 범용적인 명령어 및 동작을 통해서 이용이 가능하다. 따라서 작동의 감지도 어려울 뿐 아니라 해당 코드가 공격 코드인지 판단하는 것도 어렵다.

하드웨어적 취약성이기 때문에 OS 환경 제약을 받지 않는 다는 것 역시 문제다. 보통 맥OS나 리눅스에서는 대부분 사용자 권한만 가지고도 대부분의 악성코드를 차단할 수 있었지만 위에서 보았다 시피 자바스크립트 가지고도 동작이 가능했기 때문.

무엇보다도 절망적인 것은 멜트다운 취약점의 원인이 십수년간 변하지 않은 (특히 인텔) CPU 하드웨어 구조적 문제라 업데이트같은 소프트웨어적 해결책으로 완전한 해결을 보장할 수 없다는 것이다. 이는 그 어떤 소프트웨어이든 하드웨어 위에서 구동되는 이상 어쩔 수 없는 한계다. 실제로 소프트웨어적인 패치는 모든 멜트다운 공격을 막을 수 없다는 전문가 의견이 있다. 즉 실질적으로 멜트다운 취약점을 이용하지 못할 정도로 업데이트가 가능할 수도 있지만, 그렇게 되지 않을 가능성도 있는 것이다. 설령 공격의 난이도가 높아도 취약점 공격의 대가가 크다면 이용의 어려움이고 뭐고 없이 달려들 수도 있는 것이고. 이 문서에 서술된 '멜트다운' 취약점에 한정한다면 OS의 최적화 과정을 포기해서 커널과 유저의 페이지 테이블을 분리하는 정도로도 충분한 방어가 가능하지만, 이건 CPU 자체의 한계를 해결한 것이 아니라 그 약점이 악용될 가능성 중 하나를 막은(혹은 어렵게 한) 것에 불과하다. 즉, 구조적으로 하드웨어 차원에서 해당 문제의 근본적인 해결이 되지 않는 한 해당 취약점을 악용할 가능성은 남아 있을 수 있다. 그리고 이런 경로 모두를 실제 악용 전에 미리 발견하는 것이나, 설령 발견하더라도 소프트웨어적인 해결책을 찾아내는 것은 현실적으로 매우 어렵다.

인텔 CPU 사용시 설령 성능 저하가 있더라도 OS가 이 문제를 틀어막아주지 않으면 안 되는 이유다. 따라서 기존의 보안 문제하고는 차원이 다르게 범용성 높은 취약점이다. 다만 커널의 어느 값이나 쉽게 읽을 수 있을 뿐 어디를 읽어야 하는지 알아내는 과정에는 상당한 연구가 필요하고, 그렇게 기를 써서 뚫어봤자 캐낼만한 값진 정보를 가진게 아니기에 당장 개인 사용자를 타겟 삼아서 취약점을 악용하는 사례는 나오지 않을 가능성이 높다. 그러나 기업이나 공공기관 같은 곳은 일단 뚫기만 한다면 매우 값진 기밀 정보를 담고 있을 것이 100%이기에 무슨 짓을 해서라도 접근하려는 시도가 많아질 수 있으며 무엇보다 타인과 공동으로 사용하는 클라우드 환경 역시 매우 취약해지게 된다. 일단 구글에서는 구글 클라우드의 가상화 시스템의 특성상 멜트다운/스펙터 취약점을 이용하는 것이 불가능하다고 발표했지만 다른 곳도 안전하다는 보장은 없다.

만약 패치로 보안 문제를 완화하는데 실패할 경우, 결국 CPU를 완전히 바꿔야 하는데, 인텔의 경우에는 2011년 샌디브릿지 아키텍처 기반의 2세대 코어 i 시리즈부터 거의 모든 CPU가 해당되며, 잠재적으로는 1995년 11월에 등장한 펜티엄 프로부터, 일반 사용자 기준 1997년 5월에 등장한 펜티엄 2부터 해당되는 거의 모든 인텔 CPU에 취약 가능성이 있으므로, 현재로선 다른 인텔 CPU로 교체라는 선택지는 사실상 존재하지 않는다. 이렇게 되면 결국 인텔의 CPU를 AMD의 ZEN 아키텍처 기반 CPU로 옮기는 것 외엔 방법이 없다. 이로 인해 들어갈 각종 비용은 계산이 어마어마하다는 것은 조금만 생각해 봐도 알 수 있다.

3.2. 스펙터

한편 스펙터(또는 스펙터 익스플로잇)는 멜트다운 버그와 비슷하게 추측 실행(speculative execution)으로 인해 일어나기는 하지만, 조금 덜 심각하다. 하지만 그렇다 해도 심각한 건 마찬가지이다. 가장 원초적이면서 가장 기본이 되는 가장 깊은 곳에서, 절대로 남이 봐서는 안 되는 정보가 해킹될 수 있기 때문. 또한 후술하다시피 스펙터는 구현하기가 어렵지만, 기어코 구현되고 나면 발견하는 것은 물론, 발견하더라도 막는 것도 그만큼 어렵다. 스펙터는 추측 실행을 할 때 다른 곳의 코드 실행[15](분기표적 주입(branch target injection)의 경우)이나 조건문(경계검사 우회(bounds check bypass)의 경우)을 실행한 뒤 잘못된 경우에 취소시키는데, 이때 비슷한 부작용이 발생하는 점을 악용하여 다른 프로그램의 메모리를 읽어들이는 것이다.

다만 메모리를 훔쳐볼 수만 있고 메모리에 기록할 수는 없으므로 그 자체만으로 직접 시스템에 파괴적인 행동을 하거나 랜섬웨어 등 악성코드를 심는 것은 불가능하다. 또한 커널 영역 메모리에 접근 가능한 것은 아니므로 상대적으로 멜트다운보다는 시스템에 끼치는 영향은 좀 더 적을 것으로 보인다. 하지만 다른 프로세스의 메모리에 올라온 모든 정보를 해커가 읽을 수 있는 이상, 직접 각종 개인정보를 유출하여 이메일, 검색포털, 스팀, 배틀넷 등의 계정을 탈취하거나, 최악의 경우 은행 공동인증서 비밀번호와 기타 온라인 뱅킹 전자서명까지 죄다 털리고 현금이 인출되는 상황이 벌어지거나 하는 일이 벌어질 가능성은 있다. 게다가 이러한 일련의 공격을 막기 위해 데이터를 암호화하는 것도, 그 암호의 복호화 키가 메모리에 있는 한 키 역시 같이 유출될테니 근본적인 해결책이 되지 않으며, 상술했듯이 공격을 수행하는 것 자체를 막는 것도 악성코드의 소행인지를 판단하기 어렵기 때문에 어려운 것도 문제다.

스펙터 버그의 경우 유저들의 프로그램간 메모리 스니핑이 일어나는 거긴 하지만, 기본적으로 대상 프로그램에서 문제가 존재하는 코드의 추측 실행이 돼야 하기 때문에, 실제 버그를 이용해 공격하려면 공격하려는 대상 프로그램을 세세하게 분석해야 되고, 프로그램이 돌아가는 CPU 아키텍처나 운영 체제에 대해서도 자세히 알아야 되고, 실제로는 취약점을 공격하긴 매우 어렵다. 그래서 현재까지 실질적으로 해당 취약점의 영향을 받는 곳은 런타임에 JIT 컴파일러에 의존하는 자바스크립트 엔진과 그 웹브라우저들뿐이다. 단, 어느 코드에서나 문제가 존재할 가능성이 있기 때문에, 문제를 발견해 막기도 힘들다(그래서 이름이 유령, Spectre이다.). 예를 들어 프로젝트 제로측에서는 리눅스 커널상에서 실행되는 패킷 필터 JIT 컴파일러를 이용해 문제가 되는 코드를 커널 컨텍스트상에서 만들어 실행시켰다. 그래서 스펙터의 경우 긴급 보안 패치는 난이도를 훨씬 더 어렵게 만들어 놓은 것이다.

문제는 스펙터 취약점 또한 하드웨어 구조적 결함이라 업데이트같은 소프트웨어적 미봉책으로는 사실상 완전히 막을 수 없다는 것이다. 스펙터 버그의 공동 발견자 중 한 명인 폴 코처(Paul Kocher)에 따르면, 스펙터 버그가 소프트웨어 패치로 해결되지 않는다고 한다. 멜트다운 버그가 긴급한 위기인 반면, 스펙터 버그는 모든 고성능 프로세서에 영향을 끼칠 수 있으며, 성능에 중점을 둔 설계가 이러한 버그에 취약하게 만들었다고 한다. 즉, 성능과 보안을 모두 얻으려던 업계의 갈망이 불가능하다는 것을 보여주는 사례가 스펙터 버그이며 새로운 설계의 프로세서가 나오기 전까지 존재할 것이라고 한다. 스펙터 버그는 수십년간 사용된 프로세서 설계에 존재하는 결함이기 때문이다.

스펙터 버그는 멜트다운 버그에 비해 심각성이 적다고 여겨지지만, 현대의 고성능 CPU 중에 스펙터 버그에 면역인 CPU가 존재하지 않고, 면역이 되기 위해서는 성능을 포기해야 하며, 어느 정도로 위험한지는 감도 안 잡히는 상황이고, 현재 상황으론 얼마나 완화될 수 있는지도 미지수인데 근본적인 해결법은 새로운 설계의 CPU 밖에 없어, 가볍게 여겨져서는 안 될 것으로 보인다. 2019년 2월 Ars Technica 기사에 따르면 현 시점에서 스펙터 버그는 추측 실행을 포기하지 않는 이상 완전히 막을 수 없는 것으로 여겨지고 있다. 스펙터 버그를 이용해 메모리 구조를 파악하게 되면 해당 구조에 맞는 다른 취약점을 통해 임의의 코드를 성공적으로 실행할 수 있을 가능성이 높아지기에 이 취약점과 관련된 문제들이 지속될 것으로 예상된다.

3.3. 추후 발견된 취약점

멜트다운과 스펙터를 연구하면서 발견된 새로운 취약점들.

3.3.1. 인텔 AMT 관련 추가 보안 문제

원문 / 보도문 /

핀란드의 보안 회사 F-Secure에서 인텔의 일부 CPU에서 추가로 문제점을 발견했다. 멜트다운, 스펙터보다 심각한 문제라고 한다. AMT 기술은 현재 vPro 기술을 사용하는 전세계 약 100만대의 기업용 컴퓨터에 사용되기 때문에 더 큰 파장이 일어날 것이라고 한다.

AMT는 인텔의 기술이므로 AMD, ARM 등 다른 제조사의 CPU에는 영향이 없다.

그리고 공격을 위해서는 공격 대상의 PC가 부팅 후 관리자 로그인만 되어 있으면[16] 가능하며, 기본 설정에서는 해당 공격이 불가능하다. 다만 내부 보안이 허술할 경우 PC의 관리 콘솔 관리자 비밀번호를 기본값에서 변경하지 않고, 이후 PC에 허가받지 않은 사람이 접근하여 콘솔 설정을 해 놓는 일련의 상황이 가능할 수도 있다는 것이 문제. 링크

사실, 인텔 관리 엔진과 AMT 관련 취약점은 17년 5월에 한번 공지가 있었고, 해당 내용 관련 윈도우 업데이트는 17년에 이미 진행되었다. 지금 등장한 내용과 이때의 내용은 조금 다른 부분으로, AMT 관련 수정을 했다던 인텔이 다시 한번 뚫림으로써, 상당한 타격이 예상된다.

POS와 키오스크, ATM을 개발하는 미국의 NCR은 인텔 매니지먼트 엔진의 취약점을 이용해 ATM을 원격 공격할 가능성에 대해 언급했다. 인텔 ME 관련의 원격 서버 관리 버그, Intel Trusted Execution Engine 취약점을 악용해 ATM의 원격 공격이 가능하다고 하는데 이 me관련은 인텔만 사용하기에 인텔만의 문제이다. 스카이레이크/카비레이크 아키텍처 기반 ATM에 국한된 것으로, 이 회사에선 일부 커스텀 오더를 받은 제품에 여기에 해당되기에 한국에서는 해당되지 않는다. 기사

3.3.2. 스펙터 프라임 / 멜트다운 프라임

엔비디아와 프린스턴 대학 연구팀이 새롭게 발표한 취약점으로 상세 설명은 아직 공개되지 않았다. 멜트다운과 스펙터의 변종으로, 멀티코어 CPU 간의 캐시 일관성으로 인해 발생하는 문제라는 언급만 있었다. 비록 멜트다운 프라임은 실제로 구현하진 못했지만 스펙터 프라임은 구현에 성공했다. 인텔은 기존 스펙터, 멜트다운 패치가 이 문제에도 일정 부분 적용될 것이라고 한다. AMD가 이번에도 피해갈 수 있을지는 미지수인 상태. 기존 스펙터, 멜트다운을 가지고 있던 X86(특히 인텔), ARM, POWER 아키텍처 CPU는 여기에도 해당될 것으로 보인다. 일각에서 예상했던 패치 릴레이의 시작일 수도 있는 상황. 기사 번역

3.3.3. 브랜치스코프

기사 / 보고서

윌리엄 메리 대학교, 캘리포니아 대학교 리버사이드, 카네기 멜론 대학교, 빙엄턴 대학교의 연구진이 발견한 새로운 취약점이다. 인텔 SGX(Software Guard eXtension) 안에 보호받고 있는 데이터도 뚫을 수 있다. 스펙터 취약점과 마찬가지로 분기 예측 실행을 통한 취약점이다. 그렇지만 스펙터 취약점은 분기 예측 유닛의 분기 목표 버퍼를 노리지만, 브랜치스코프는 분기 예측 유닛의 패턴 히스토리 테이블을 노리는 취약점이다. 이로 인해 연구진들은 확인해 보진 않았지만 스펙터를 막기 위해 내놓은 인텔의 패치가 브랜치스코프에는 무력할 수 있다고 주장한다. 반면 인텔은 스펙터 Variant 1을 위한 패치가 브랜치스코프에도 유효할 것이라 주장한다. 스카이레이크, 하스웰, 샌디브릿지 i7과 i5에서 취약점이 확인되었다. 그렇지만 연구진들은 AMD CPU에 관한 언급은 하지 않아 AMD CPU는 무사한 건지, 아니면 아직 테스트를 못해본 건지는 알 수 없다. 하지만 스펙터 취약점과 비슷한 루트를 통한 취약점 이기에 스펙터 취약점이 있는 AMD CPU에서도 취약점이 있을 수 있다. 연구원들은 이 취약점을 해결하기 위한 세 가지 대안을 제시했다.

3.3.4. Spectre-NG 추가 발견

새로운 스펙터 취약점이 발견되었다. 인텔뿐 아니라 소수의 ARM 기반 CPU 및 AMD CPU에도 영향이 있을 수 있다고 한다.

추후 패치 예정에 있다고 한다. 스펙터 variant 4로 부르기도 한다.

3.3.5. L1TF 버그 발견

하이퍼스레딩과 관련된 버그이다. Foreshadow라는 별명이 붙었다. AMD CPU에는 적용되지 않는다고 한다.

OpenBSD의 리드 개발자 Theo de Raadt는 해당 취약점을 막으려면, 모든 인텔 CPU에서의 하이퍼스레딩을 바이오스 설정을 통해 비활성화해야 한다고 메일링 리스트에 올렸다. # 메일 내용을 보면 표현이 꽤나 과격하다. Fundamentally broken(기초부터가 잘못된), doing a terrible job(일을 엉망으로 하는), There is no time left to(시간이 부족한) 등등...게다가 아직도 추가적으로 더 밝혀질 건덕지가 있음을 예고했다.

그 와중에 인텔은 L1TF에 대해 제공한 마이크로코드 패치를 배포하면서 "패치 전후 성능을 비교하는 벤치마킹을 해선 안 된다"라는 조항을 EULA에 포함시켰다가 반발이 거세지자 다시 삭제했다. #

3.3.6. Spoiler 취약점 발견

이 취약점은 메모리 정렬 버퍼(Memory Order Buffer)에서 발생하는 문제로 스펙터와 작동 과정은 유사하지만 스펙터 해결책은 통하지 않는다. 소프트웨어를 통한 임시 대책은 없으며 재설계 이외의 해결책은 없다. 인텔 코어 시리즈 전 제품에 해당된다고 하며, AMD, ARM에서는 발견되지 않았다. 소프트웨어(OS, 가상머신, 샌드박스) 환경을 가리지 않는 문제로 서버에서는 또다른 날벼락인 셈.

3.3.7. 좀비로드/폴아웃(=MDS) 취약점 발견

인텔 내/외부 전문가들이 찾아낸 취약점으로, 프로그램이 읽을 수 없는 데이터를 읽을 수 있다고 한다.

이 취약점을 활용하면 웹사이트에 악성코드를 숨길 필요도 없고 방문자가 사이트를 여는 순간 정보를 훔칠 수도 있다는데 이를 입증하는 데모와 POC 코드가 'ZombieLoad'라는 사이트에 공개되어 누구나 열람이 가능한 상태로 확인됐다.

성능 하락은 3%이고, HT을 껐을 경우 최대 19% 하락한다고 한다.

2011년후부터 나온 인텔 CPU, 즉 샌디브릿지 이후 대부분의 CPU들이 해당된다. 하이퍼스레딩의 허점을 노려 공격 가능하며 실시간 키보드 입력이나 가상머신의 데이터를 훔쳐 볼 수 있다. 관련 보안 업데이트를 하면 CPU 성능이 떨어지는 문제가 발생한다.

리눅스 관련 정보를 다루고 있는 Phoronix에서 스펙터와 멜트다운을 포함해 최신 보안 이슈가 시스템 성능에 미치는 영향을 조사한 결과는 테스트에 사용한 인텔 CPU 4종 제온 E3-1275 v6, 8700K, 7980XE, 9900K의 평균 하락율은 16%로 조사됐고 AMD CPU 2종 2700X, 2990WX는 3%로 조사되었다.

문제의 원인으로 지목된 하이퍼스레딩을 끄면 차이는 더 커졌다는데 애플의 발언대로 40% 가까이 나는 게 사실일지도 모른다.

3.3.8. SWAPGS 취약점 발견

기존의 멜트다운과 스펙터 방어 기능을 우회하는 새로운 CPU 취약점이 비트디펜더 연구원들에 의해서 발견되었고 인텔 CPU가 취약점을 나타냈다.

기존 방어 기능을 우회하는 새로운 스펙터급 CPU 취약점 발표…비트디펜더

2018년에 발견했으나 대처할 시간을 주기 위해 인텔과 MS 등 관계자들에게만 통보한 상태로 1년 가량 발표를 연기했었다. 2019년 7월 중에 윈도우 보안패치를 통해 SWAPG 위험성을 완화했으므로 반드시 설치하는 편이 좋다. Intel CPU의 추가 보안 취약성, Microsoft만 수정 패치

원리는 최신 CPU의 추측 실행(speculative execution) 메커니즘을 악용해, 윈도우 패치 이전의 모든 보안체계와 KASLR(Kernel Address Space Layout Randomization) 보안체계를 우회하여 커널 메모리의 내용을 읽어내 유출하는 방식. 특정 메모리 커널의 값을 확인하여 스펙터 1의 방식처럼 메모리 내용을 유출시킬 수 있다. 다행히 스펙터 버전 1 유형과 유사한 SWAPGS 공격은 소프트웨어 패치로 완화할 수 있으므로, 직접적인 바이오스나 마이크로 코드 업데이트 까진 필요하지 않다고 한다.

AMD 라이젠의 경우엔 설계구조가 인텔과 달라 SWAPG를 쓰지 않아서 면역이라 한다. 기사에 따르면 "비트디펜더 연구원들은 하이퍼-V 커널과 젠 하이퍼바이저(Xen hypervisor) 커널에 대한 빠른 분석 결과, SWAPGS 명령이 사용되지 않았기 때문에 악용이 불가능한 것으로 나타났다. 이 연구원들은 “다른 운영체제와 하이퍼바이저는 조사되지 않았지만, 발표를 조정하는 동안 마이크로소프트는 모든 관련 당사자에게 이 취약점에 대해 알렸다."

Digitaltrends의 영문 기사에 따르면 2종의 AMD CPU를 테스트했으나 보안의 허점은 찾지 못했다. 원문은 "“We tested two AMD CPUs: AMD64 Family 16 Model 2 Stepping 3 AuthenticAMD ~3211 Mhz and AMD64 Family 15 Model 6 Stepping 1 AuthenticAMD ~2100 Mhz and neither exhibited speculative behavior for the SWAPGS instruction,” it said in a statement, via BleepingComputer." 전문링크(영문)

AMD의 공식 홈페이지 링크에서도 AMD 제품은 SWAPGS 추측에 따른 새로운 GS 값을 추측하지 않도록 설계돼서 영향받을 가능성은 낮다고 자체적으로 판단하고 있다. Updates SWAPGS (CVE-2019-1125) 8/6/19 항목 참조

3.3.9. NetCAT 보안취약점 발견

인텔 제온 시리즈에서 또 다시 메모리 속의 암호와 중요한 정보가 유출되는 치명적인 보안 취약점이 발견되었다. NetCAT 취약점이라 불리고 있으며 인텔 제온 시리즈 계열에서 나타난다.

퀘이사존 참조링크, 영문 참조링크

2019년 9월에 암스테르담 자유 대학의 연구원들이 발표한 보안 취약점은 Xeon CPU에서 사용하는 인텔 기술인 DDIO(Data-Direct I / O Technology) 또는 원격 다이렉트 메모리 엑세스(Remote Direct Memory Access)에서 나타나며, 네트워크상에서 접근할 수 있는 보안 취약점이므로 매우 위험하다고 한다.

원칙적으로는 로컬 액세스를 거쳐 보안을 확보해야만 SSH 보안 세션 등의 정보에 접근할 수 있다. 그런데 속도를 올리기 위해 CPU와 이더넷 사이의 전달경로를 직통으로 열어버린 통에 보안 취약점이 생겨 네트워크상에서 신뢰할 수 없는 장치까지 부채널 공격을 통해 SSH 세션에 접근 가능한 사단이 일어난 것. SSH 세션에는 유저가 입력한 키라든지, 패스워드 등의 치명적인 정보가 존재하므로 유출될 경우 악용 가능성이 무궁무진하다.

암스테르담 자유 대학의 연구원들은 인텔 기술인 DDIO 등을 사용하지 않는 AMD는 버그의 영향을 받지 않는다고 밝혔다. 인텔의 경우 DDIO나 RDMA를 사용하지 않는 CPU는 다행히 NetCAT 보안취약점이 나타나지 않는다.

3.3.10. TSX ATA & JCC 취약점

2019년 11월 인텔이 발표한 자사 제품군의 77개 취약점 목록 중 중요한 2가지 취약점.

TSX ATA 취약점은 TSX 기능이 들어간 프로세서가 대상이 된다. MDS 취약점을 연구하다가 발견되었다고 한다.
JCC 취약점은 CPU에서 디코딩된 ICache와 관련된 버그라고 한다. 마이크로코드 업데이트로 완화시킬 수 있으나 성능이 0 ~ 4% 가량 떨어진다고 한다. #

3.3.11. 플런더볼트(Plundervolt) 취약점

2019년 12월 경에 아래 기사에서 언급된 특정 모델 인텔 CPU의 취약점들이 보도되었다.

인텔 SGX(Software Guard eXtension) 엔클레이브 관련 이슈. 오버클럭 등을 위해 CPU에 보내는 전압을 수동으로 조절할 때 발생하는 헛점으로 인한 보안 문제이다. 기사에 따르면 해커가 원격조작을 통해 코드를 실행시키는 방식으로도 달성 가능한 것으로 확인됐다.

인텔 데스크탑, 서버 및 모바일 CPU 중에 스카이레이크 세대부터 시작해서, SGX가 지원되는 제품들을 공격할 수 있다. 다행히 스카이레이크 이전 세대 인텔코어 프로세서는 저전압 인터페이스가 있어도 SGX와는 관련이 없어 다행히 피해갔다고 한다.

해당 공격 방식은 인텔 보안 방식인 SGX가 작동하여 방어하기 전에 공격하는 방식이며, 만약 공격에 성공하면 해커가 운영 체제(OS)권한을 엑세스 할 수 있게 된다.

기사에 따르면 인텔 CPU 모델 중에 특정 레지스터가(Model Specific Register, MSR) 존재하는 경우, 이걸 외부에서 소프트웨어로 작동시킬 수 있는 동적 전압 제어(Dynamic Voltage Scaling, DVS) 기능을 악용하는 방식이라고 한다. 소프트웨어의 취약점이 발생한 CPU 유형은, 컴퓨터가 쓰는 작업량에 따라 CPU가 자동으로 클럭 주파수와 전압량을 조절해 전력 소모와 온도를 조절하는 알고리즘의 취약점에서 나온 것이라고 한다.

영국 버밍엄 대학교, 오스트리아 그라츠 공과대학, 벨기에 루벤대학(KU Leuven)의 학술 연구팀이 밝혀냈으며, 플런더볼트(Plundervolt)라는 새로운 유형의 오류 삽입 공격으로 정의했다.

취약점을 지닌 모델들은 방어를 위해 신규 바이오스 업데이트와 보안패치가 필요하며 성능저하가 생길 가능성도 있다.

이것은 SGX의 취약점으로 SGX를 사용하지 않다면 바이오스에서 비활성화 하는 것으로 취약점을 막을 수 있다. SGX에 대한 설정을 따로 한 적이 없다면 메인보드 바이오스 단에서 기본적으로 off 상태에 있을 것이며 드라이버 설치도 안 된 상태다.

컴퓨터를 평범하게 쓴다면 잘 모를 수 있지만, 인텔 CPU를 제대로 쓰겠다는 사람들에겐 청천벽력과도 같은 소식이었는데, 이 취약점으로 인해 언더볼팅을 사용할 수 없도록 패치가 이뤄진 것. 이 때문에 AMD 라이젠 CPU가 들어간 노트북으로 갈아탄 유저가 꽤 많다.

인텔 CPU 오버클럭커들 보안 비상?, 수동 전압 입력시 보안 취약점 발생, 2019/12/11

인텔 SGX 엔클레이브, CPU 전압을 조작하는 원격 공격에 취약, 2019/12/12

3.3.12. 캐시아웃(CacheOut) 취약점

2020년 1월 경에 CVE-2020-0549 취약점이 보도되었다. #
2018년 4분기 이전의 Intel CPU는 모두 해당하는 취약점이라고 한다.

자세한 내용은 캐시아웃(컴퓨터 보안) 문서를 참고.

3.3.13. LVI 취약점

Load Value Injection의 약자이며, 인텔의 SGX를 활용한다.[17] 기존의 모든 취약점 방지책이 쓸모없으며, 막기도 기존 취약점들에 비해 더 어렵고, 소프트웨어적으로 어떻게든 막고 나면 SGX를 활용한 연산이 2~19배 더 오래 걸리게 된다고 한다.

스카이레이크 이전 세대 아키텍처들이나 다른 회사의 아키텍처들은 SGX가 없으니 당장은 해당사항 없음. 다만 멜트다운 취약점이 나중에 IBM POWER9, ARM Cortex-A75 등에도 적용 가능한 것으로 밝혀진 전례가 있는 만큼 당장 해당사항이 없다 해도 방심은 금물. ~~그것도 그렇지만 일단 4k 블루레이를 PC에서 보려면 SGX가 필수인데 이젠 못본다~~ UHD 블루레이에 SGX가 필요하게 된 것은 영화사에서 요구한 DRM 때문이었는데, UHD 블루레이 출시 당시였던 하스웰 시절에도 순수 소프트웨어 렌더링은 하이엔드 CPU에서는 가능했다. MakeMKV 같은 프로그램이 DRM을 해제해 주기는 하지만 모든 타이틀이 다 되는 것도 아니다.

4. 해당 버그에 취약한 하드웨어

스펙터 버그는 동시에 여러 명령어를 처리하는 CPU에서는 공통적으로 발생이 가능하다. 즉, 인텔, AMD, ARM 등 모두 해당된다. 현재까지 완전 면역으로 밝혀진 CPU는 명령어를 순차 처리하는 구형 저성능 CPU들만 존재하는 상황이다. # 마찬가지 이유로 알려진 GPU의 경우는 해당사항이 없다. 만약 이들이 취약점에 노출되었다면 권한 없이 타 애플리케이션의 화면을 탈취하는 것이 가능했겠지만, 현존하는 GPU들은 극단적으로 데이터 병렬화를 추구하는 방향으로 발전했고, 그 덕분에 예측실행과 OoOE 기능을 탑재하지 않았다. 비유하면 한 칩에 구형 CPU를 무식하게 많이 때려박은 것.

멜트다운 버그에 공식 홈페이지의 취약한 CPU에서는 아이태니엄과 2013년 이전의 아톰 프로세서를 제외한 모바일, 데스크톱 컴퓨터 기종을 불문하고 '1995년 이후 나온 비순차 처리를 이용하는 모든 인텔 프로세서는 잠재적으로 해당된다고 하며, 출시일이 2011년인 모델까지 거슬러 올라가며 테스트한 결과 멜트다운 취약성이 확인되었다고 했다. 버그 공개 초기의 문서라서 그런지 여기에서는 AMD와 ARM은 확실하지 않다고 했다.

인텔과 관련하여 잠재적으로 해당되는 제품들까지 좀 더 자세하게 표로 만들면 다음과 같다.

출시연도	제품군	비고[18]
1995	펜티엄 프로	P6
1997	펜티엄 II
1998	펜티엄 II Xeon
1998	셀러론
1999	펜티엄 III
1999	펜티엄 III Xeon
2000	펜티엄 4	넷버스트
2001	제온
2002	셀러론
2003	펜티엄 M	2세대 P6
	셀러론 M	2세대 P6
	펜티엄 4 EE	넷버스트
2004	셀러론 D
2005	펜티엄 D
2005	펜티엄 XE
2006	코어	3세대 P6
	코어 2	코어
	제온
2007	펜티엄 듀얼 코어
	셀러론
	셀러론 M
2008	코어 i7	[커피R]
2009	코어 i5	[커피R_일부] [코멧]
2009	제온	-
2010	코어 i3	[코멧]
2010	펜티엄	-
2011	셀러론	[코멧]
2011	제온 E3/E5/E7	-
2013	아톰	실버몬트 이후
2017	코어 i9	[24]
	제온 W	[25]
	제온 Scalable	[캐스캐이드]
2018	제온 D	[휴잇]
	제온 E	[커피R_일부]
	펜티엄 골드	[코멧]
	펜티엄 실버	-

즉 P6 아키텍처 이후의 인텔 x86 기반 프로세서 거의 전부가 멜트다운 버그에 취약하다. 테이블에 서술된 펜티엄 제품군은 P6 아키텍처 기반인 펜티엄 프로, 펜티엄 2부터 펜티엄 듀얼코어 시리즈 [30]까지 해당되고, 셀러론 제품군은 펜티엄 제품군에 사용된 아키텍처에서 파생된 보급형 제품군이기 때문에 P6 아키텍처 기반의 초창기 셀러론 제품군부터 스카이레이크 아키텍처 기반의 현세대 셀러론 제품군까지 모두 해당된다. 2008년부터 2013년 이전에 출시된 본넬 아키텍처 기반의 아톰 프로세서는 비순차적 실행을 지원하지 않아 해당 사항이 없다. 또한 x86과 호환성이 없는 IA-64 기반의 아이태니엄 프로세서는 x86 아키텍처가 아니라서 유사한 결함이 있는지 시험한 바 없다.

TECHARP에서도 영향 받는 제품 목록을 제공하고 있다.

1월 6일에는 애플(맥, 아이폰, 아이패드, 애플 TV[31]), 닌텐도(스위치)가 3가지 공격 모두에 취약함이 밝혀졌다. 반면 AMD는 유형 2(스펙터 - BTI), 유형 3(멜트다운)는 해당하지 않고 유형 1(스펙터 - BCB)은 긴급패치되었다. 참고 [32]

닌텐도 스위치의 프로세서( 테그라)를 생각하면 NVIDIA까지 불똥이 튈 수도 있는 상황이다. ARM도 점점 심각해지는 게, 유형 3a에 영향받는 '일부'의 목록이 길어지고 있다. 자체 아키텍처로 선회한 삼성 엑시노스, 퀄컴 스냅드래곤은 아직 문제점이 보고되지 않았다.[33]

일본 4gamer.net의 분석글, 해석

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)에 취약하다. #

5. 취약점에 대한 대응

미국 국토안보부, 미국 국방부, FBI의 사이버보안 고문 기관인 CERT/CC는 소프트웨어가 아닌 CPU 아키텍처 자체의 결함이기 때문에 업데이트는 미봉책일 뿐이며, 보안 취약점이 발견된 인텔, AMD, ARM 등의 CPU의 교체가 필요하다는 권고안을 내렸다. 하지만 이 권고안은 다음날 철회되었으며 CERT/CC는 OS, CPU 마이크로코드, 애플리케이션을 업데이트를 하라는 새로운 권고안을 내렸다.
프로세서를 교체하는 것이 근본적인 해결책이지만, 추측 실행을 사용하지 않는 고성능 프로세서가 존재하지 않아 현재는 대체할 프로세서가 없기에 지금 당장 사용할 수 있는 해결책은 아니다. 때문에 CERT/CC가 권고안을 철회한 것으로 보인다. 사실 일반적으로 떠올리기 쉬운 CPU제조사로 보더라도 저 범위에서 사실상 벗어나지도 않기도 하고 ARM의 경우에는 ARM 기반의 CPU를 통칭하다 보니 범주에서 벗어나는 CPU를 찾는 게 더 어려워진다.

CERT/CC와 동일하게 CPU 교체가 필요하다는 권고안을 내린, 미국 국토안보부 산하의 US-CERT도 해당 권고안을 철회하고 보안 패치를 받으라는 새로운 권고안을 내렸다. 또한 보안 취약점이 CPU 아키텍처에 있기 때문에, 패치가 모든 경우의 보안 취약점에 대한 해결책이 되지 못할 수도 있다고 덧붙였다. US-CERT가 권고안을 수정한 이유도 CERT/CC와 같은 것으로 보인다.

구글은 성능저하 없는 스펙터 취약점 패치 레트폴린(Retpoline)을 공개했다. # Windows 10의 경우 1903 버전부터 적용할 것으로 보인다. #(바이너리 자체는 1809 버전부터 들어있다고 한다.)

5.1. Intel

2018년 1월 4일, 인텔의 공식 성명이 나왔다.

인텔은 악의적인 목적으로 사용되었을때 시스템에서 민감한 데이터를 탈취할 수 있는 소프트웨어 분석 방식에 관한 새로운 보안 연구에 대해서 인지하고 있습니다. 이번 보안 문제가 데이터를 손상, 수정, 삭제할 잠재력은 없습니다.[34] 보안 문제가 '버그'나 '결함'으로 인한 것으로 인텔 제품에만 존재한다는 것은 잘못되었으며, 인텔 CPU뿐만 아니라 다른 프로세서에서도 나타날 수 있습니다. 인텔은 이러한 보안 문제를 해결하기 위해 AMD, ARM, OS 회사 등과 함께 협력하며 제품과 소비자 보안을 위해 노력하고 있습니다. 보안 패치가 성능에 미치는 영향은 작업량에 따라 다르며, 일반적인 유저에게 있어선 큰 영향이 없을 것이며 시간에 따라 나아질 것입니다[원문2]. 업데이트가 가능해지는 즉시 업데이트를 하시고, 업데이트를 하시기 전까지 악성 소프트웨어를 방지하는 보안 수칙을 따르십시오.

인텔은 자사 홈페이지에 보안 이슈에 대해 정리한 글을 게시했다. 해당 글에서 인텔은 엔드 유저에게 업데이트가 가능해지는 즉시 업데이트를 할 것을 권장했다. 또한 보안 버그를 악용하는 악성 소프트웨어로부터 시스템을 보호하는데 도움이 되는 보안 수칙으로 다음과 같은 예시를 들었다.[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)는 인터뷰에서 이번 보안 이슈는 해결 불가능한 문제가 아니기 때문에 리콜은 없을 것이라고 밝혔다.

2018년 1월 5일, 인텔은 두 개의 기사를 자사 홈페이지에 게시했다.

첫 번째 기사에서 인텔은 자사 시스템에서 멜트다운 버그와 스펙터 버그를 막을 수 있는 업데이트를 개발했으며, 배포하고 있다고 밝혔다. 인텔은 지난 5년간 출시된 대부분의 프로세서를 위한 업데이트를 이미 배포했으며, 다음주 말까지 지난 5년간 출시된 프로세서의 90% 이상을 위한 업데이트가 배포될 것이라고 밝혔다. 또한 많은 OS 회사, 공공 클라우드 서비스 제공 업체, 디바이스 제조사 등과 같은 업체들은 이미 제품과 서비스를 업데이트했다고 밝혔다.
성능 저하 이슈에 대해서는 작업량에 따라 다르며, 일반 유저들에게 있어선 큰 영향이 없을 것이며 시간에 따라 나아질 것이라는 기존 입장을 고수했다. 일부 특정한 작업량에서는 성능 저하가 다른 작업량에 비해 초기에는 높을 수 있지만, 테스트와 소프트웨어 업데이트의 개선 등으로 성능 저하를 완화시킬 것이라고 밝혔다.

두 번째 기사에서 인텔은 파트너사와 함께 멜트다운 버그와 스펙터 버그 보안 패치가 성능에 주는 영향을 측정하는 대규모 테스트를 진행하고 있다고 밝혔다. 또한 인텔은 성능 하락이 거의 없거나 전무하다고 밝힌 애플, 아마존, 구글, 마이크로소프트의 조사 결과를 인용했다. 인텔은 성능 저하는 작업량에 따라 다르며, 일반적인 유저들에게 있어선 큰 영향이 없을 것이며 시간에 따라 나아질 것이라는 기존 입장을 다시 한번 더 고수했다.

2018년 1월 9일, 인텔의 CEO 브라이언 크르자니크는 CES 2018 사전 기조연설을 멜트다운 버그와 스펙터 버그에 대한 언급으로 시작했다. 크르자니크는 여러 프로세서 아키텍처에 존재하는 업계의 보안 이슈를 해결하기 위해 수 많은 기업들이 협력한 것은 정말 놀라웠다고 밝혔다. 크르자니크는 이어, 인텔이 보안 문제를 해결하기 위해 노력하고 있으며, OS 회사와 시스템 제조사의 업데이트를 가능한 빠르게 받는 것이 데이터를 안전하게 보호하는 데 최선의 행동이라고 밝혔다. 또한 일주일 동안 5년간 출시된 프로세서와 제품의 90% 이상을 위한 업데이트가 배포되었으며 1월 말까지 나머지 제품을 위한 업데이트가 배포될 것이라고 밝혔다. 성능 저하는 작업량에 따라 다르며, 일부 특정한 작업량에서는 성능 저하가 다른 작업량에 비해 높을 수 있지만, 업계와 노력해서 지속적으로 성능 저하를 최소화할 것이라고 밝혔다.[37]

해당 연설에서 크르자니크의 '수많은 기업들이 협력한 것은 정말 놀라웠다.'라는 발언이 자화자찬이 아니냐는 기사가 있다.[38] 또한 보안 이슈에 대한 사과가 없다는 점을 꼬집은 외신이 있다.

2018년 1월 10일, 인텔은 보안 이슈에 관한 기사를 자사 홈페이지에 게시했다. 해당 기사에서 인텔은 현재까지 멜트다운 버그와 스펙터 버그를 이용한 어떠한 데이터 탈취도 발견되지 않았다고 밝혔다. 인텔은 12월 초에 OEM 파트너사에게 인텔 펌웨어 업데이트를 제공하기 시작했으며, 일주일 동안 5년간 출시된 프로세서와 제품의 90% 이상을 위한 업데이트가 배포되었으고, 1월 말까지 나머지 제품을 위한 업데이트가 배포될 것이라고 밝혔다.

인텔은 최근의 PC 성능 테스트에 근거하여, 일반적인 컴퓨터 사용자에게 큰 성능 저하가 없을 것이라고 밝혔다. 또한 일반적인 가정과 비즈니스 PC 사용자들은, 이메일 읽기나 서류 작성 혹은 디지털 사진을 엑세스 하는 것 같은 일반적인 작업에서 큰 성능 저하를 겪지 않을 것이라고 밝혔다. 인텔은 SYSmark 2014 SE 테스트에서 SSD와 8세대 코어 프로세서가 장착된 컴퓨터에서 6%나 그보다 적은 성능 저하를 보였고 SYSmark의 개별 테스트에서는 2%에서 14%의 성능 저하를 보였다고 밝혔다. 데이터 센터의 성능 저하는 현재 조사하고 있는 중이며 클라우드 서비스 등을 제공하는 여러 업계 파트너사의 조사에서는 성능 저하가 작거나 거의 없다는 결과가 나왔다고 밝혔다.

전반적인 성능 저하는 특정 작업량, 플랫폼 구성, 성능 완화 기술에 따라 다르다고 밝혔다. 또한 경우에 따라 여러 가지 성능 완화 옵션이 있으며, 각각 성능에 미치는 영향과 구현 세부사항이 다르다고 밝혔다. 더 많은 자세한 내용은 인텔의 백서와 구글의 "레트폴린(Retpoline)" 보안 솔루션 게시물에서 찾을 수 있다고 밝혔다. 인텔은 업계와 함께 성능 저하가 큰 경우를 해결하는 해결법을 계속해서 찾고 있다고 밝혔다.

2018년 1월 11일, 인텔은 클라이언트 시스템의 초기 성능 테스트 결과를 공개했다. 서버 플랫폼의 초기 성능 저하 테스트 데이터는 며칠 뒤에 공개하겠다고 밝혔다.
윈도우 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를 사용했을때는 이보다 성능 저하가 더 낮았다고 밝혔다.[39] 인텔은 추가 테스트를 수행할 때마다 결과가 변경될 수 있다고 덧붙였다.

인텔은 광범위한 용도의 인텔 플랫폼 성능 테스트 결과를 모으고 있으며, 다음주 안에 지난 5년간 출시된 모바일, 데스크탑 플랫폼의 데이터를 제공할 것이라고 밝혔다. 인텔은 업계 파트너사와 함께 성능 저하를 가능한 줄이기 위해 여러 해결책들을 만들고 있으며, 현재 출시된 제품뿐 아니라 미래에 출시할 제품의 보안과 성능을 극대화하기 위해 노력하고 있다고 밝혔다.

2018년 1월 12일, 인텔 CEO 브라이언 크르자니크는 자사 홈페이지에 기술 업계 선두 기업을 위한 글을 올렸다. 글에서 크르자니크는 1월 말까지 지난 5년간 출시된 제품의 업데이트를 마치고 그후에는 구형 제품의 업데이트를 배포하겠다고 말했다. 이어, 인텔 홈페이지에 지속적으로 보안 패치 진행 상황과 성능 데이터 등을 게시할 것이라고 말했다. 마지막으로, 모든 업계의 보안을 강화하기 위해 중요한 보안 취약점은 공개적으로 밝히고, 업계와 협력하며 사이드 채널 공격(side-channel attacks)을 방지하는 하드웨어 혁신을 업계와 공유할 것이며, 잠재적인 보안 위협 연구를 위한 연구에 기금을 지원할 것라고 말했다.

2018년 1월 12일, 인텔은 몇몇 시스템 특히 하스웰과 브로드웰 시스템에서 펌웨어 업데이트를 적용한 후 자주 재부팅 현상이 일어난다는 보고가 있었으며, 만약 이 문제가 개선된 펌웨어 업데이트가 필요하다면 제공할 것이라고 밝혔다. #

2018년 1월 21일, 리눅스의 아버지인 리누스 토르발스가 인텔이 내놓은 패치 내역을 검토하고 이에 대한 평가를 했는데, 취약점 보완 상태를 선택적으로 취할 수(통보할 수) 있게 설정해 둔 사실을 발견했다. # 다시 말해서 멜트다운 보안 패치는 단순히 수정하는 것으로 끝나지만 '스펙터'의 경우 OS에게 수정 사항을 활성화할 건지 말 건지 OS에 선택권을 제공하고 있다는 뜻인데, 리누스는 해당 스펙터 패치가 성능 저하를 일으키기 때문에 벤치마크에서 이것이 반영될 부분을 의식해 켜고 끌 수 있게 남겨 두었다고 비판했다. 인텔이 성능 저하가 없어야 하는 스펙터 패치에서의 성능 저하를 숨기기 위해 벤치마크에는 OFF 상태에서 측정한 값을 결과로 발표했다고 한 것이다. 또한 무한 재부팅 등 다른 문제가 생겨, 인텔은 자사가 만든 스펙터 패치를 사용하지 말라고 권고했다. #

2018년 1월 26일 인텔은 보안을 강화하여 칩셋을 새로 내기로 했다. 씨넷코리아, the gear보다 근본적인 재설계와 같은 방식보다는 보안 장치를 내장하는 방식을 통해 인텔에게서 최대 문제인 멜트다운 부분을 해결하겠다는 것으로 보인다.

2018년 2월 22일 6~8세대 마이크로코드 업데이트가 배포되었다. 3월 3일에는 4, 5세대 마이크로코드 업데이트가, 3월 13일에는 2, 3세대 마이크로코드 업데이트가 배포되었다. Windows 10의 경우, 2018년 5월 17일 KB4100347 보안 업데이트를 통해 마이크로코드 업데이트를 배포했다. # #

2018년 4월 인텔 마이크로코드 업데이트 가이드에 따르면 블룸필드, 블룸필드 제온, 클락스필드, 걸프타운, 하퍼타운 제온 C0, 하퍼타운 제온 E0, 재스퍼 포레스트, 펜린/QC, SoFIA 3GR 아톰, 울프데일 C0, 울프데일 M0, 울프데일 E0, 울프데일 R0, 울프데일 제온 C0, 울프데일 제온 E0, 요크필드, 요크필드 제온을 포함한 과거 제품에 대한 마이크로코드 업데이트는 포기한 것으로 보인다.

하드웨어 설계 자체를 변경하여 물리적으로 대응한 것은 커피레이크 리프레시 통칭 9세대부터이다. 커피레이크 리프레시 제품이라고 해도, 일부 제품만 해당하니 주의. 제품별 스테핑 정보
2019년 9월 기준으로 최신인 R0 스테핑은 폴아웃, 좀비로드, 멜트다운에 대응한다. 이보다 구식인 P0 스테핑은 폴아웃에 대응하지 못하고 좀비로드, 멜트다운에는 대응한다. 더욱 구식인 U0 스테핑은 물리적 대응이 전혀 되어 있지 않은 제품이다.

5.2. AMD

한편 AMD 측의 분석 결과 발표에 의하면, 구글 프로젝트 제로팀에서 언급해 준 취약점 중 스펙터 버그에 해당되는 "경계검사 우회(Bounds Check Bypass)" 변수는 OS/소프트웨어 업데이트로 해결이 되었으며 업데이트로 인한 성능 저하는 무시할 수 있는 수준이라 했고, "분기표적 주입(Branch Target Injection)" 변수는 아키텍처 구조 상 문제 발생 가능성이 매우 낮으며, 아직까지 성공이 확인된 사례는 없다고 했다. 그리고 멜트다운 버그에 해당되는 "불량 데이터 캐시 적재(Rogue Data Cache Load)" 변수의 경우도 마찬가지로 아키텍처 구조의 차이로 문제가 없다고 했다.

분기표적 주입의 경우, 아직 공격 성공 사례는 없지만, 문제가 되는 추측 실행의 근본적인 원리는 AMD에도 해당되므로 선택적 마이크로코드 업데이트를 내놓기로 했다.[원문4] # (14번째 댓글 참고)

비전문가도 읽고 이해할 수 있도록 아주 깔끔한 해명을 해서 간만에 AMD PR이 일 잘했다는 칭찬이 나왔다. 참고로 ARM 홀딩스도 대응이 괜찮았다고 한다.

그리고 2018년에 Zen과 Zen+ 아키텍처에서는 마이크로코드 패치로 대응을 하며, 2019년에 나올 Zen 2 아키텍처에서는 하드웨어 구조 변경을 통한 스펙터 완전 대응을 예고했다.

5.3. OS

리눅스 커널에는 패치가 적용된 상태다. 처음 멜트다운 취약점 해결 패치가 적용된 리눅스 커널은 아키텍처에 관계 없이 기본적으로 해당 보안 기능이 실행되기 때문에 성능저하를 막기 위해서는 커널 옵션에서 이 기능을 꺼 줘야 했으나[41], 새 패치가 나오면서 인텔 CPU에서만 실행되도록 변경되었다. 어떤 인텔 엔지니어가 그냥 모든 CPU에 패치가 적용되게 만들었다가 리누스 토르발스한테 걸려서 메일로 구수한 쌍욕을 얻어먹기도 했다. 쌍욕 먹어도 할 말 없는 문제다. 자사의 문제점을 해결하는 패치로 타사의 제품까지 성능을 낮췄으니. ~~인텔에서 물타기 시전한 걸 생각해보면 엔지니어 개인이 결정한것은 아닌 것 같다~~

마이크로소프트에서 사태가 정말로 시급하기에[42], 원래 정기 업데이트로 예정한 날짜였던 1월 9일이 아닌, 한국 날짜 1월 4일 오전 6시에 윈도우 10에서만 긴급 업데이트를 실시했다. 관련 기사 업데이트 내용 추가 설명 [43]

이미 11월 경 MS측에서 해당 문제에 대한 확인이 진행되었다. 알렉스 이오네스쿠 트위터
맥의 경우 17년 12월 6일에 정식 보안 패치가 완료되었다.

macOS High Sierra 10.13.2의 보안 콘텐츠, 보안 업데이트 2017-002 Sierra 및 보안 업데이트 2017-005 El Capitan에 관하여

5.4. 웹 브라우저, 그 외

기계어로 번역되는 자바스크립트를 통해 버그를 트리거할 수 있다는 점이 알려지면서 주요 브라우저들이 임시 방편을 적용했다. 브라우저 수준에서 취약점을 막긴 어렵지만, 공격이 나노초 단위의 정밀한 시계를 필요로 하기 때문에 우선 시계의 정밀도를 임시로 낮춰 놓은 것이다.(취약점이 여전히 남아 있지만 공격 속도를 수천배 이상 낮출 수 있다.) 각 브라우저 별 상황은 다음과 같다.[44]

Firefox 57.0.4 (1월 4일 발표)
네이버 웨일 v1.0.39.11 (1월 11일 발표)
Chrome 64 (1월 23일 발표)
크롬인 경우 79.0.3945.88 기준으로 사이트격리(Site Isolation) 가 기본적으로 실행되어있어 굳이 따로 설정해줄 필요는 없다.
작동되고 있는지 확인하려면 메뉴-더보기-작업관리자 를 선택해 사이트와 서브프레임의 프로세스ID가 다른지 확인하면된다.
윈도 7/8.1/10용 Internet Explorer 및 엣지 (1월 3일 발표)

그래서 여기에 따르면 브라우저 자바스크립트 동작에 멀티스레딩을 도입할 때 추가적인 보안 정책을 서버에 명시하지 않으면 SharedArrayBuffer 타입 변수 등 멀티스레드 지원에 필요한 기능을 쓸 수 없게 변경되었다.

6. 사용자가 할 수 있는 대처법

6.1. 취약 여부 확인

윈도우에서는 MS에서 공개한 파워셸 스크립트를 통해 확인할 수 있다. #
PowerShell을 관리자 권한으로 실행 후 아래 명령을 한줄 씩 차례대로 입력한다. ( Windows Terminal을 통해 PowerShell을 실행하는 경우라면 저 여섯줄을 한꺼번에 붙여넣기 하고 예기치 않은 명령이 실행될 수 있다는 창에서 '붙여넣기'를 선택하면 된다.) 중간에 모듈 설치나 실행 규칙 변경 여부를 물으면 Y를 입력한다. (실행 규칙의 경우에는 마지막 줄의 명령어를 통해 원래대로 되돌아갈 것이다.)

#!syntax powershell
Install-Module SpeculationControl -Scope CurrentUser
$SaveExecutionPolicy = Get-ExecutionPolicy
Set-ExecutionPolicy RemoteSigned -Scope Currentuser
Import-Module SpeculationControl
Get-SpeculationControlSettings
Set-ExecutionPolicy $SaveExecutionPolicy -Scope Currentuser

다섯번째 줄의 명령어를 실행했을 때 한줄이라도 붉은색 텍스트가 표시된다면 조치가 필요한 것이다. 취약하지 않거나 대응 조치가 완료되었다면 녹색 텍스트가 표시된다. 각 항목의 의미는 링크를 참조. #

스펙터 멜트다운 CPU 체크 프로그램으로 테스트 해볼 수도 있다. 관련 기사 다운로드한 파일을 실행한 뒤 start security check 버튼을 누르면 된다. update_ash.exe 파일만 생성되고 실행이 되지 않는다면, 작업관리자로 강제종료한 다음, 파일 속성에 들어가서 차단 해제를 해주고, update_ash.exe 파일 삭제 후 다시 실행하면 된다.

Inspectre라는 프로그램도 있다. 취약점 확인 외에 성능 저하를 대략적으로 확인해주는 기능도 존재한다. 특이하게도 취약점 대비를 켜거나 끄는 기능도 존재한다. 취약점 대비가 안 되었거나 하드웨어 자체에 취약점이 없는 경우 해당 기능이 활성화되지 않는다. 기능 자체는 MS가 패치에 포함한 기능으로 레지스트리를 통해 조절한다. 그냥 개인도 버튼 하나만 눌려서 쓰기 쉽게 해주는 프론트엔드인 것. 참고로 끈 다음에 그냥 재실행하면 계속 켜져있는 것으로 나올 때가 있는데, 이럴 때는 윈도우를 재부팅한 후에 다시 실행해 보면 정상적으로 반영되는 것을 볼 수 있다. 현재 추가적인 업데이트가 되고 있지 않기 때문에, 멜트다운과 스펙터 취약점에 대해서만 확인 가능하고, 이후 밝혀진 취약점에 대해서는 전혀 알 수 없으니 주의.

6.2. 메인보드 펌웨어 업데이트

프로세서 제조사가 업데이트된 마이크로코드를 제공하고 메인보드 제조사가 그 마이크로코드를 탑재한 펌웨어를 공개, 그리고 최종적으로 사용자가 그 펌웨어를 자신의 메인보드에 업데이트해야 한다. 멜트다운과는 달리 스펙터는 커널 수정만으로 방어할 수 없으며, 펌웨어 패치까지 이루어져야 한다. 최신 펌웨어라고 해도 2018년 이전에 공개되었으면 취약점이 해결되지 않았을 확률이 높다. 스펙터 대응 펌웨어는 2018년 1월에 소수 모델용이 겨우 배포되기 시작했다. 구형 마더보드를 쓰고 있으면 메인보드 교체만이 답인 것이다.

인텔에서는 5년 내에 출시된 CPU에 업데이트를 제공하겠다고 발표 #했으며, 나중에 취약점을 해결한 마이크로코드를 배포했다. 2013년 출시작인 아이비브릿지 EP/EX 및 하스웰 이후 CPU들에 해당. #

참고로, 기가바이트의 GA-B150M-D3H 메인보드는 1월 16일 자로 CPU 마이크로코드가 업데이트된 새 버전의 펌웨어가 올라왔는데, 펌웨어 업데이트 전에는 스펙터에 취약하고 멜트다운에는 안전하다는 결과가 나왔는데(윈도우 10 보안 패치는 적용한 상태) 펌웨어를 업데이트하고 스펙터 멜트다운 CPU 체크 프로그램을 돌리니 스펙터와 멜트다운에 모두 안전하다는 결과가 나온다.

현재 메인보드 주요 제조사 ASUS, GIGABYTE, MSI에서는 9 시리즈 칩셋까지 새로운 펌웨어를 제공하겠다고 밝힌 바 있다. 하지만 9 시리즈는 3사 모두 X99 칩셋만 해당되어 사실상 하스웰-E 모델 및 브로드웰 이후로만이 될 것으로 보인다. ASRock은 8 시리즈 칩셋까지로 공지가 올라왔으나 실제로는 7 시리즈 칩셋까지 제공하고 있다. Q77을 제외한 Z77, H77, B75 칩셋 한정. 6 시리즈 칩셋은 제공하지 않는다.

한편, HP에서는 자사 제품들에 대해 2월 중에 모두 패치하겠다는 입장을 견지했지만, 어느 순간 패치들이 줄줄이 취소되며 '인텔 측에서 개선된 마이크로코드를 내놓지 않으면 우리는 업데이트가 불가능하다'는 답변을 내놓았다. 업데이트 일정이 적혀 있던 공식 문서는 날짜만 줄줄이 TBD[45]로 교체된 채 방치되어 있다. 일단 인텔에서 코드를 줘야 패치가 가능한 사정상 어쩔 수 없는 것은 알겠지만, 인텔과 다를 바 없이 너무 무성의한 태도라는 것이 중론. 때문에 HP 사용자들이 공식 포럼을 통해 끊임없이 항의하고 있다. 그런데 문서가 갱신된 4월 11일 기준 일부 제품을 제외한 90% 이상의 제품들의 업데이트가 올라왔다고 문서가 수정되었다. 또한, 아직 업데이트가 나오지 않은 제품들은 TBD가 아닌 Pending으로 상태가 변경되었다. 위 링크로 들어가 자신의 모델을 검색 후 펌웨어 버전에 Pending이나 TBD가 아닌 버전명이 적혀있을 경우 반드시 업데이트 하자. HP Support Assistant를 이용해도 되지만 업데이트가 뜨지 않을 때에는 직접 홈페이지에서 펌웨어 업데이트를 다운받아 업데이트하면 정상적으로 적용이 된다. 적용 후에는 멜트다운과 스펙터에 취약점이 없다는 결과가 나오는 것을 확인했다.

2018년 3월 31일 기준으로 ASUS B150M-A 메인보드의 경우 새 버전의 펌웨어가 제공되었다. 펌웨어 업데이트 결과 관련 프로그램을 통해 확인된 결과에 따르면 멜트다운과 스펙터 모두 안전하게 나왔다. 참고로 새로운 펌웨어를 업데이트 하기전에는 스펙터에는 취약하다는 결과가 나왔다.[46]

인텔 아톰 시리즈 중 클로버트레일 이후 CPU는 제조사에서 해당 펌웨어 업데이트가 없는 것 같았지만, 3월 30일 기준 8인치 윈도우 태블릿의 대명사였던 델 베뉴 8 프로가 해당 취약점이 패치된 마이크로코드를 적용한 펌웨어 업데이트가 나왔다. 펌웨어 적용 후 검사해보니 안전하다고 결과가 출력된다. 다른 윈도우 태블릿들도 해당 제조사의 홈페이지에 들어가 반드시 펌웨어 업데이트가 있는지 확인한 후 적용하자.

보증기간이 지난 세대 보드에는 업데이트를 안 해주는 경향이 있다. #(ASUS고객 센터 답변을 받은 사람이 포럼에 올린 것이다. 내용은 펌웨어 업데이트는 안 하지만 인텔에서 마이크로코드 패치는 해줬으니 사용자가 알아서 리눅스 깔아서 리눅스 패치를 통해 적용하라는 얘기.)
보다 못한 VMware가 해당 패치를 윈도우 드라이버 차원으로 끌어다 설치할 수 있는 방법을 개발했다. # 가상화 기능 개발사이다보니 리눅스용 패치를 윈도우 드라이버에다 끌어붙인 모양.

6.3. 윈도우

윈도우 7, 8.1, 10의 경우 2018년 1월 이후에 나온 누적 업데이트 롤업을 설치하면 멜트다운 패치가 된다. 차례대로 설치할 필요없이 최신 버전의 누적 업데이트 하나만 설치하면 된다. 자동 업데이트 기능을 켜놨다면 대개 알아서 해당 업데이트가 설치된다. 만약 설치가 되지 않을 경우 마이크로소프트 카탈로그 사이트에 들어가 자신에게 맞는 업데이트를 설치한 뒤, 재시작하면 된다. Win + R키를 눌러 실행 창을 띄운 뒤 Winver를 입력하면 창이 하나 뜨는데, 버전 xxxx라고 나온 번호가 자신의 버전이다.

이외의 윈도우 운영체제는 여기서 받으면 된다. 윈도우 서버제품군은 일반버전이 있고, XP는 패치가 없으나 POSready의 패치를 이용하는 방법이 있다고 한다. 키를 고쳐서 POSready 버전으로 인식한 다음, 보안 업데이트를 진행하는 방법인데, 바로 설치하면 문제가 생기기 때문에 우선 일반용을 설치한 다음, 레지스트리를 수정해 POSready를 올리는 식으로 했다는 말도 있다. 비스타의 경우 서버 2008용을 올리면 설치된다.

스펙터의 경우 펌웨어 업데이트로 해결해야 되나, MS에서 따로 마이크로코드 업데이트를 공개했다. 현재는 인텔 코어 i 시리즈 중 4세대 이후의 CPU만 지원하며 윈도우 10 전용이다. 이전 버전은 여전히 펌웨어 업데이트를 해야 된다. 해당 업데이트는 자동 업데이트로 배포되지 않기에 직접 다운로드후 설치해야 하며 펌웨어 업데이트가 이루어진 경우 굳이 설치할 필요는 없다. 다만 윈도우 10 버전 1809 버전부터는 스펙터 패치가 기본 내장된다고 한다.

2018년 5월 17일에 1803 버전용 패치가 나왔다. 이전 패치들과 달리 지원 대상이 2세대 코어 i 시리즈(샌디브릿지)까지 확대되었다. # 21일에는 이전 패치들도 샌디브릿지까지 지원으로 업데이트된 버전이 나왔다. # 7월 25일 다시 업데이트된 버전으로 교체되어 나왔다. #
2018년 8월 22일 또 새버전이 나왔다. # 이번 패치는 L1TF까지의 변종에 대응하기 위해 나온 것이라 기존 패치를 설치한 경우에도 설치해야 되는 것으로 보인다. 10월에 더 업데이트된 버전이 나왔다. # 11월 말에는 윈도우 10 1809 버전용도 나왔다. # 19년 2월 4일자 버전도 나왔다. 코어 1세대 지원도 추가되었다. #

2019년 초에 출시될 예정인 1903 버전 업데이트에 스펙터 성능 향상 패치가 계획되어 있다. # # 기존 30%의 성능 저하를 1~2%까지 대폭 개선했다고 한다. 2019년 3월 정기 업데이트 이후 1809 버전에도 적용 되었다. #, #

2020년 9월에 새로운 버전이 나왔다. #, Microarchitectural Store Buffer Data Sampling (MSBDS) 등 새로운 보안 취약점 대응 버전이다. 인텔 문서, MS 문서

RTM[A]	다운로드
버전 1607[A]	다운로드
버전 1703	다운로드
버전 1709	다운로드
버전 1803	다운로드
버전 1809	다운로드
버전 1903 / 1909	다운로드
버전 2004 / 20H2	다운로드

업데이트 이후 일부 PC에서는 SPTD를 인식할 수 없는 오류가 발생해 DAEMON Tools를 비롯한 상당수의 가상 CD 이미지 파일 프로그램들을 사용할 수 없게 되는 문제가 있었다. 얼마 뒤 2018년 1월 19일, SPTD가 업데이트돼서 최신 SPTD를 설치하면 문제가 해결된다.

6.4. macOS

Mac App Store에서 업데이트를 통해 High Sierra 10.13.2를 설치하면 된다. 초기에는 하이 시에라만 멜트다운 패치까지 제공되고 시에라와 엘 케피탄은 스펙터 패치만 제공되었지만, 1월 23일에 해당 버전들을 위한 멜트다운 패치가 공개되었다. 2018-001 보안 업데이트를 설치하면 된다. # # 요세미티 이하 버전은 패치가 제공되지 않는다.

6.5. 리눅스

리눅스도 배포판 업데이트를 하면 된다. 애초에 이 버그는 이렇게 빨리 공개될 예정이 아니었고, 오픈 소스인 리눅스 커널을 패치하던 중 수상한 패치 요약이 개발자들의 의심을 사는 바람에 빨리 공개된 것이다. 버그를 모르는 사람이 보기엔 합리적인 근거 없이 I/O 성능을 대폭 깎아먹는 패치가 올라온 것이니 의심할 수밖에 없다. 즉, 리눅스에선 버그 발표보다 패치가 올라온 게 더 빨랐다. 물론 각종 Linux 배포판들이 새로운 커널을 공식 지원해서 업데이트를 유도하고 설치하는 건 별개의 일이라 발표 전 미리 리눅스 서버들에 대비가 되어 있었다는 건 아니다.

7. 사건 여파

7.1. 보안 패치 후 하드웨어 성능 하락

하드웨어의 취약점이기 때문에 이를 OS와 커널 등 소프트웨어 수준에서 해결하려면 성능 하락이 발생하게 된다. 현시점에서 보안 버그 패치 시 성능 저하를 피할 수 있는 방법은 없다고 전문가들이 전했으며, 일부 유저들은 1월 9일 뒤에 상황을 보고 나서 더 논해보자는 신중론을 보이고 있다.

취약점이 공개되기 전 레딧에서 언급된 테스트 결과는 상당한 성능 하락을 보였기에 큰 논란이 되었다. 작업별 테스트 결과 게임 테스트 결과

역시 실제 패치가 진행되기 전 인사이더 패스트링 빌드로 올렸던 윈도우 10 버전 1803 빌드 17035로 테스트한 결과도 비슷했는데 읽기 속도도 감소했지만, 쓰기 속도의 경우 심각하게 감소했음을 확인할 수 있다. 다만 이는 960 EVO 특유의 캐시 특성에 따른 결과일 확률이 높다. 캐시 메모리를 다 사용한 후 유동적으로 적용되기 때문에 값이 요동친다는 주장이며 이 말대로라면 패치 이전 값 역시 편차가 클 것이고 실제로 MLC인 950 Pro, 960 Pro로 측정했을 시 패치 이후 심각한 성능 하락은 없다. 위 유튜브 링크 중 950 Pro로 측정한 값이 있는데 실제로 16K에서 약간 하락한 것 빼곤 거의 차이가 없다. 또한 버전 1803 빌드 17035 테스트의 경우는 보안 패치 이외에 기능 업데이트로 인한 영향일 수도 있다. 같은 삼성의 850 EVO의 경우도 업데이트 전후로 읽기, 쓰기 속도가 모두 20% 가까이 하락한다는 벤치 결과가 있다. # 850 EVO 역시 TLC와 캐시 구조를 가진다. SATA 버전의 경우 일부 항목은 변화가 없는 경우도 많다.

다만, NVMe 형식의 SSD의 경우는 그보다 더 하락폭이 더 커졌으며, 성능이 높을수록 그 폭은 더 커진다. SATA와 비교해서 PCIe 컨트롤러를 통해서 CPU와 직결되기 때문인 것도 있지만, SATA 형식의 SSD와 비교해서 속도 자체가 더 빠르기 때문에 그 폭이 더 커진 것으로 추측된다.

패치 이후에는 다소 다른 결과가 나오기 시작했는데 가장 논란이 되었던 성능 하락을 확인하기 위한 유튜브에 올라온 업데이트후 진행된 벤치마크 결과 영상이다. # 전반적으로 1~2% 정도의 차이를 보이며 특정 벤치마크는 업데이트 후가 더 잘 나오기도 한다. 측정 편차에 의한 오차를 감안하면 일반사용에 있어서 크게 영향을 느끼기 어려울 것으로 판단된다. 단 개인마다 컴퓨터 사양의 차이가 있어 영상결과와 다를 수 있으며, 16K 영상의 쓰기, 읽기 속도가 약 10% 정도 하락한 것을 보면 대용량 미디어 정보를 관리하는 서버는 영향을 어느 정도 받을 듯 보인다.[49]

SSD보다 메모리를 벤치를 비교해야 된다는 얘기가 있다. # #

레드햇 성능팀이 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에 따르면, 성능 하락은 작업량과 시스템 환경에 다르다고 한다. 예를 들어 순수하게 메모리 기반 연산을 하고 최소한의 소프트웨어만 구동되는 텍스트 기반 환경에서는 큰 성능 하락이 없을 것이며, 많은 저장 장치와 네트워크가 연결이 되었으며 주로 정보 저장소로 사용되는 GUI 시스템에서는 큰 성능 하락이 있을 수 있다고 한다.

현재까진 게임 성능에는 가시적인 저하가 없는 것으로 확인되었다. 업데이트를 받아보고 즉시 벤치를 돌려본 유저들의 의견에 의하면 성능상으로 큰 차이는 없다는 언급이 대부분이다. 게임은 소프트웨어를 보조기억장치에 설치해 놓고 실시간으로 리소스를 읽어오는 방식인데 위의 서술대로 쓰기 속도가 저하된다고 해도 읽기가 대부분인[50] 게임엔 영향을 미치치 않을 수도 있다. 애초에 위와 같은 쓰기 속도 저하도 일반적인 것은 아니었지만.

하스웰부터 지원하는 INVPCID 기능으로 인해 이전 CPU들보다 성능 하락폭이 다소 줄어들었다고 한다. 그렇다고 성능하락이 없는 수준은 아니다.
MS의 설명에 따르면 스카이레이크 이전 세대의 경우 분기 예측을 아예 꺼버린다고 한다. 한마디로 기능 자체를 쓰지 못하는 셈.
구글과 아마존닷컴 측은 멜트다운, 스펙터 버그 패치로 인한 성능 저하 논란은 과장된 이야기이며, 자사의 서버나 클라우드 서비스도 이렇다 할 퍼포먼스 하락은 보이지 않는다고 언급했다. # 마이크로소프트는 자사의 Azure 서버가 보안 패치 이후 뚜렷한 성능 하락은 보이지 않는다고 밝혔다. # 애플은 보안 패치 이후, GeekBench 4나 Speedometer, JetStream, ARES-6같은 일반적인 웹 브라우징 벤치마크로 테스트했을 때, macOS와 iOS에서 주목할 만한 성능 하락은 보이지 않는다고 밝혔다. #

구글은 자사 보안 블로그를 통해 자체 개발한 보안 패치 기술, 레트폴린(Retpoline)을 공개했다. 해당 패치는 스펙터 취약점 중 하나인 분기표적 주입(branch target injection)에 대한 패치이다. 구글에 따르면, 해당 기술이 해킹 위험을 없애면서도 CPU 성능 저하도 막을 수 있다고 한다. 구글은 해당 기술을 업계 파트너사와 공유할 것이며 성능에서 무시할 만한 영향을 준다고 발표했다.

에픽게임즈에 따르면, 클라우드 서비스 서버에 멜트다운 대응을 위한 업데이트를 한 뒤, 클라우드 서비스 서버의 CPU 사용량이 크게 올라갔다고 한다. #, [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% 정도 하락했다.[51]

삼성 SDS에서 자체적으로 실시한 결과 데이터센터에 따라서 최대 60%라는 경이로운 속도하락을 보여주었다고 한다.

인텔의 스펙터 패치 이후 성능 하락이 없다고 발표한 것이 사실은 해당 패치 기능을 꺼놓고 돌린 것이라 욕을 먹고 있다.

윈도우 10 1803 버전에서 스펙터 패치를 적용했을 때 SSD 4K 성능이 반토막난다고 한다. 실제로 성능 저하가 확연히 느껴진다는 사람들도 있다.

7.2. 패치 자체의 문제

i5 1세대 CPU(린필드)에서 패치 이후 지속적으로 컴퓨터가 강제 종료되는 현상이 일부 사용자에게서 발생한다고 한다. 또 하스웰(4세대) 칩에서는 패치를 하면 강제 재부팅 현상이 발생한다고 한다. # PC가 무작위로 꺼졌다가 켜진다는 것이다. 12일 나온 WSJ 기사에 따르면, 인텔은 보안패치의 결함을 인정하고 일부 고객에게(하스웰 사용자들) 패치를 설치하지 않도록 권고했다. 그러다가 인텔 코어 2~7세대 내장 그래픽 사용자는 재부팅 현상도 발생되기 시작했다. 기사

결국 인텔은 패치 배포를 중단했다. 기사 이후 2018년 3월에 2~8세대 cpu를 대상으로 새로운 마이크로코드 업데이트가 배포되었다.

한편 일부 구형 AMD 시스템(구형 애슬론에서 문제가 있었다고 한다.)에서도 패치 이후 컴퓨터가 부트되지 않는 문제가 발생했다고 한다. # 이유는 일부 AMD 칩셋이 AMD가 제공한 문서대로 작동하지 않기 때문이었다고. MS와 AMD는 일단 이 패치를 AMD 시스템에서 받지 못하게 했으며 며칠 후 해당 문제를 해결한 패치가 나왔다.

이외에도 메모리 관련 패치다 보니 산업용 임베디드 시스템에서 문제가 많다고 한다. 기사 2010년대부터는 공장이라도 랜섬웨어 공격을 당하는 등 보안에서 안전 지대가 아니기 때문에 보안 패치가 필수가 되어가는 상황인데 이런 식으로 문제가 생기면 답이 없다. 다만 대부분의 자동화공장 설비는 오프라인된 폐쇄 시스템이긴 하다.(인터넷에 연결이 되어 있지 않아 그 공장 건물, 정확히는 공장 건물 내부가 인트라넷 밖에서 접근할 회선 자체가 없다는 것. 하지만, 내부에 미리 침투해 있는 사보타주의 공작으로 장악당한다면 털리게 될 것이므로 오프라인 폐쇄 시스템의 특징이 무의미 해질 것이다.)

8. 이후 전개

멜트다운 버그의 구조에 대해 잘 모르던 개인 사용자들에게는 대응 패치 이후 성능 저하 여부만 주목받았으나, 사실 멜트다운 버그의 핵심 부분은 보안 취약점이기 때문에 성능 저하는 어디까지나 덤에 가깝고, 보안 문제가 훨씬 더 심각하다.
인텔 개인 컴퓨터의 성능 저하는 다음과 같다. 게임프레임은 영향없으나 스펙터 유형2를 위한 메인보드 펌웨어 업데이트까지 할경우 SATA 방식은 약간의 영향이 있으며, NVMe 방식 SSD는 심각하게 떨어진다. NVMe 방식 SSD의 경우 성능이 높을수록 떨어지는 수치가 높으며 CPU가 구형일수록 이 수치는 더 떨어진다. CPU를 많이 쓰는 서버에는 누적 성능 저하가 더 심각하게 영향을 주고 있다. 이게 원인은 의외로 단순하다. SATA 방식은 메인보드 칩셋의 관리영역이기에 CPU의 영향으로부터 어느 정도 자유롭지만, NVMe 방식은 PCI-Express이기에 아무래도 CPU의 영향을 받을 수밖에 없다는 거다.
인텔의 무성의한 대응이 사태를 더욱 악화시키고 있다. 이 버그도 대응이 무성의하지만, 그 직전에 일어난 인텔 관리 엔진 관련 보안 버그도 굉장히 무성의한 대응으로 일관 중이고, 이 문제도 현재진행형이기 때문. ~~레노버, 에이서, Dell, H P, 삼성, LG 등의 완제품 PC 제조사들: 아이고 두야.~~
스펙터의 경우에는 AMD도 이 문제에서 완전히 자유로운 것은 아니며, 또한 대다수의 모바일 CPU가 위협에 노출되어 있다.
CEO 브라이언 크르자니크를 포함한 인텔 전현직 고위 간부들은 2017년 11월부터 12월까지 CEO의 경영권 보장 분의 주식 등을 제외한 본인들이 팔 수 있는 한계 안에서 모두 주식을 매각했다.[52]
인텔, CPU 보안 결함과 관련해 집단소송 피소.[53]
인텔이 애플에게는 무려 수개월 전에 이 취약점에 대한 정보를 전달한 것으로 보인다. 애플이 macOS의 멜트다운 취약점 관련 패치를 6월에 했기 때문.
구글이 인텔에 수 개월 전부터 이를 통보했으나 인텔 측에서 무시, 심지어 인텔의 CEO인 크르자니크 역시 이를 알고 있었음을 실토.
구글이 문제있음을 알린 때가 2017년 7월인데, 이 시기에 인텔이 커피레이크를 출시했다. 즉, 제품에 보안 문제가 있는 것을 알고도 그 제품을 출시 연기나 취소 없이 그대로 출시한거다.
닌텐도 스위치를 포함한 여러 콘솔 게임기들의 불법 복제 및 보안 체계 붕괴 우려. 특히 닌텐도 스위치는 최근 엔비디아 테그라 칩셋에 의한 보안이 뚫려 PSP의 커펌 문제가 재발할 가능성이 매우 높아져 심각한 문제가 될 수도 있다. 반면 플레이스테이션 4( Pro 포함), 엑스박스 원( X 포함)은 AMD의 CPU를 쓰기 때문에 영향이 적다. 스위치는 구 버전 펌웨어에서는 홈브루가 돌아가는 수준이며 몇몇 해킹 그룹이 개발완료 혹은 개발중이며 곧 공개한다며 입을 털고는 있지만 아직까지 보안체계 완전 붕괴까지는 오지 않았다.
미국 상원 은행위원회 소속 상원의원 2명은 증권 거래 위원회와 법무부에 인텔 CEO 브라이언 크르자니크가 내부자 거래법을 위반했는지 조사해줄 것을 촉구했다. # 인텔은 모든 정부 조사와 수사에 협조하겠다고 밝혔다.

프로젝트 제로 게시글에 따르면 각 CPU 벤더들의 반응은 다음과 같다.

인텔은 답변을 전혀 주지 않았다고 한다. (No current statement provided at this time.)
AMD는 홈페이지에 각 취약점의 영향과 해결 방법을 공지했다. #
ARM은 해당 취약점에 영향을 받는 칩셋과 해결 방법에 대한 페이지를 공개했다. #

상황 초기에 비해 개인 사용자 사이에서의 성능 저하는 잠잠해졌지만, 맨 위에 있는 멜트다운 데모 동영상이 공개되자 보안 결함이 예상보다 훨씬 심각한 상황이었음이 알려졌다. 보안패치가 필수가 된 만큼 CPU의 성능 저하가 적다고 해도, 하나하나의 성능 저하가 누적될 만큼 여러개, 대량의 CPU를 사용하는 서버와, 클라우드 컴퓨팅 회사들이 큰 영향을 받을 것으로 보인다. 마이크로소프트, 구글, 바이두, 드롭박스 등 여러 회사들은 AMD EPYC 시리즈를 이미 여러 서버에 적용 중이며, 이번 보안 문제로 인해 인텔의 보안 관리 능력에 의심을 가진 회사가 늘어나 AMD의 서버 시장 점유율이 높아질 가능성이 있다. 근본적으로는 하드웨어 문제라 현존하는 최선의 해결책은 AMD EPYC 시리즈로 옮기는 것밖에 없다. 물론 스펙터 취약점은 AMD에도 존재하지만, 멜트다운과 스펙터 모두 가지고 있는 인텔보다는 낫다.

현재 인텔의 창업주를 포함한 핵심 인력들은 은퇴[54]하거나 퇴사[55], 사망[56]한 지 오래이고 R&D 조직이 망가졌다는 내부 소식이 있다( 번역본). 최악의 경우 리콜 후 보상으로 인해 인텔이 엄청난 경영난을 겪을수도 있다. 한 전문가에 따르면, 리콜 비용이 약 270억 달러 이상, 한화로 약 29조 원 이상이 될 것이라고 한다. 2018년 1월 4일 기사에 의하면 인텔은 멜트다운과 스펙터로 인한 리콜은 없다고 밝혔다. # 사실 그도 그럴 것이 1995년 이후 생산된 대부분의 CPU에 보안 결함이 있는 상황에서 리콜을 한다 해도 보상해 줄 CPU가 없다.

인텔은 이번 이슈로 인해 하루 만에 주가가 7% 가까이 하락했다. 한편 지난 석달 새에 인텔의 크르자니크 CEO를 포함한 주요 고위층 간부들이 주식을 매도해왔다는 사실이 보도되어 이미 간부들은 이 사실을 미리 알고 주가가 하락하기 전에 손을 턴 것이 아니냐는 의혹이 제기되고 있으며 사실일 경우 이는 모럴해저드, 노블리스 오블리주에 관한 중요한 문제다. # 때문에 현재 2명의 미국 상원의원이 증권 거래 위원회와 법무부에 인텔 CEO를 조사해줄 것을 촉구하고 있는 상황이다.

또한 이미 구글 측에서 이런 보안 취약성에 대한 연구결과를 인텔 측에 따로 제보했음에도, 인텔에서는 별다른 조치를 취하지 않았으며, 위에 적혀있듯이 CEO를 포함한 임직원들은 해당 소식을 들은 후부터 몇 달동안 주식을 팔아버리기도 했다.

한편 인텔 측에서는 다른 CPU도 문제가 있다고 언급했는데, 이는 사실이기는 하나 멜트다운 취약점과 스펙터 버그는 무게와 양상이 다른 버그인데 멜트다운 취약점에 대한 이야기는 다른 CPU에는 해당되지 않음에도 모든 CPU의 동일 문제인 듯한 뉘앙스로 언급한 것은 엄연한 물타기이다.

대부분의 인텔 CPU가 하드웨어적으로 문제점이 있다는 것이 드러나자 난리가 났으며 위에서 이야기하다시피 보안 패치는 근본적인 해결책이 되지 못한다. 그동안 인텔 CPU를 쓴 기기들은 취약점에 고스란히 노출될 수밖에 없고, 소프트웨어 패치로 버티거나 AMD의 ZEN 아키텍처 기반 CPU로 갈아타는 것 외엔 별다른 방법이 없다. 다만 일반인의 경우 NVMe SSD의 성능하락외 다른 성능 하락에 대해 크게 걱정할 부분이 없으나 각종 서버 등 기업용 제품의 경우 문제가 될 수 있다. CPU 교체 이외에는 근본적인 해결책이 없어서 매우 난감한 상황.

미국의 정보 기술 연구 및 자문 회사인 가트너의 부회장 네일 맥도널드는 현재 문제 해결은 재설계밖에 답이 없다고 이야기를 했다. 물론 그때까지 CPU 장사를 아예 접었다가는 도산을 피할 수 없으므로, 인텔은 기존 마이크로아키텍처는 그대로 둔 채로 보안 칩만 단 새 프로세서를 전격 출시하여 피해를 최소화하기로 결정했다. #1 #2 보호장치를 내장한 것이기 때문에 보드나 CPU쪽에 추가될 것으로 예상되며 이는 근본적인 부분에서 해결을 하기에는 로드맵만 짜는데 최대 4년이라는 긴 세월이 소요될 수밖에 없기 때문에 멜트다운과 같은 가장 큰 보안문제를 해결하기 위한 방법으로 일단 보안 칩을 달아 최악의 상황을 피하기로 결정한 것. 당연하게도 인텔의 이 소식이 들려오자마자 인텔의 주가는 상승했다.

구글 측에서 밝힌 보안 취약점 보고서에서 AMD는 스펙터 버그에만 해당하는 유형 1, 2의 가능성만을 가지고 있다고 했으며, 유형 3인 멜트다운은 아키텍처가 달라 해당사항이 아니라 했다. 스펙터 유형 1은 이미 윈도우 업데이트와 리눅스 업데이트로 해결이 된 상태이며, 스펙터 유형 2는 자체실험 결과 발견되진 않았다고 하지만, 돌파될 가능성은 존재를 하기 때문에 펌웨어 업데이트를 통해서 이를 해결한다고 하며, 곧 있으면 나올 예정이다.

인텔은 자신들이 알게 된 이 멜트다운과 스펙터 관련 보안 문제를 구글, 마이크로소프트 등 고객사들에게 알려줬는데 문제는 해당 기업들 중에 레노버와 알리바바가 있었고 이로인해 중국공산당 쪽으로 관련 정보가 넘어갔을 가능성이 제기되었다. 이에 반해 미국 국토안보부와 국가안보국(NSA)은 인텔로부터 아무런 연락도 받지 못한 관계로 언론에 보도가 되기 전까지 보안 문제에 대해 알지 못했다고 한다. WSJ 기사 연합뉴스

다만 인텔이 중국 공산당에 직접 통보한 적은 없다. 비즈니스 관계상 기존 협력업체에 먼저 통보한 것에 불과하고 그 목록에 레노버 등이 끼어있었을 뿐이다. 이 행위 자체는 그다지 특별할 것은 없고 실제로 중국 당국에 직접 통보했다면 일이 지금보다 훨씬 심각해졌을 것이다. 다만 여기서 문제는 중국공산당이 중국 IT 기업들을 모니터링하면서 영향력을 행사하고 있다는 점, 실제로 이 사건에서도 그런 방식으로 중국 공산당에게 정보가 흘러갔을 가능성이 높다는 점이다. 이 대목이 바로 미국에서 문제 삼는 부분이었으나 2024년 기준으로 중국 공산당과 관련에 이 보안 문제에 대해 관련 이슈가 불거진 적은 없다.

AV-Test에 따르면 1월 중 스펙터와 멜트다운 취약점을 이용한 멀웨어 샘플 139개를 바이러스 토탈에서 발견했다고 한다. 일부 샘플에는 불완전한 코드가 들어 있는 것으로 봐서 모든 샘플이 취약점 공격에 성공하진 않았을 것으로 추정된다. 기사

2018년 6월 21일 사건의 핵심 인물 중 하나인 크르자니크 인텔 CEO가 사임을 표명했다. 사유는 인텔의 관리자급 이상 간부는 내부 교제를 해서는 안 된다는 규정이라는데 석연치 않게도 과거에 이를 위반한 사실이 최근 밝혀졌다고 한다.

이 문제는 현재 진행형이며 2018년 11월에 발표된 논문에 따르면, 기존에 있었던 멜트다운 공격 중 한 가지[57]와 새로 발견된 2종의 멜트다운 공격에 대해 현재까지 나온 방어 기법으로는 여전히 취약하다는 내용이 나오며[58], 신규 멜트다운 취약점 중 Meltdown-PK는 Intel CPU의 일부가 취약하고, Meltdown-BR은 Intel과 Ryzen Threadripper 1920X를 포함한 AMD의 CPU가 취약[59]하다고 한다. 새로 발견된 5종의 스펙터 공격은 기존 방어 기법으로도 방어가 되는 것들이 있어서 논문에서는 멜트다운과 스펙터 공격을 체계적으로 분류한 것에 의의를 두는 정도로 결론을 맺고 있다. 인텔 측에서는 논문의 주장과 달리 기존 방어 기법으로 방어가 된다고 했으니 일단 어느 쪽이 맞는지는 확인이 필요한 상황이다.

애플의 경우, 2020년부터 맥북 시리즈의 CPU가 자사칩으로 교체된다는 루머가 몇 년째 나왔는데 결국 인텔조차 이러한 내용에 대해 확인을 했다는 기사가 나왔다. 물론 갑자기 맥북 프로 시리즈까지 교체하기는 당장 힘들겠지만 점차적으로 옮겨갈 계획을 몇 년간 세운 상태다. 당연하지만 인텔은 큰 고객 중 하나를 잃게되는 셈이다. 그렇지 않아도 인텔 CPU 때문에 보안패치를 할 경우 맥의 성능이 떨어지는 패치가 나온 상황이다.

2020년에 리프레쉬된 맥북 에어에는 인텔의 10세대 아이스레이크가 탑재되었으나, 관련 루머는 여전히 생산되고 있다. 특히 애플이 2021년에는 자체 개발한 ARM 기반의 칩셋을 저전력 모델에 선적용할 것이라는 전망이 나오는 등 # # 애플의 탈인텔화가 가속화되고 있다는 전망이 나오고 있다. 그리고 2020년 하반기에 신형 MacBook Air, MacBook Pro, Mac mini에 Apple Silicon제 ARM SoC이 내장되어 출시되는 것으로 결국 현실이 되었다. 자세한 건 Mac(컴퓨터)/Apple Silicon 이주 항목 참고. 다만 이는 CPU 게이트의 여파라기보다는 이전부터 진행되던 애플의 전략의 일환으로, 애플은 이미 2012년부터 자체 칩 개발을 위한 '칼라마타 프로젝트'를 진행하고, 2017년에는 아이폰에 이매지네이션 사의 GPU를 탑재하던 것에서 자체 설계한 GPU 탑재로 선회하는 등 핵심 부품은 자사에서 설계하도록 하는 전략을 진행해오고 있다.

2021년 하반기에 발표된 Windows 11에서는 TPM 2.0 의무화와 함께 인텔 8세대 이후, AMD 라이젠 2세대 이후 CPU만 지원하는 등 가혹한 CPU 제한을 걸어놓았는데, 외국에서는 Windows 11의 가혹한 CPU 제한과 TPM 의무화에 CPU 게이트가 영향을 준 것으로 추정하고 있다.

9. 기타

워낙 파급력이 큰 사건이라 트위터에서 합성 짤까지 만들어졌다.

10. 외부 링크

[1] 명령어의 비순차적 실행을 지원하는 모든 제품. [2] 다만 시스템 콜을 많이 사용하는 게임(로딩이 빈번하게 발생하거나 네트워크를 통해 전송되는 정보가 많은 온라인 게임)은 영향을 받을 가능성이 있다. 또한 게임 서버들은 네트워크 및 파일시스템 I/O와 DB 입출력이 매우 빈번하므로 여기서 성능 저하가 있을 수 있다. [3] 네할렘, 코어 마이크로아키텍처 등등... [4] 원문은 익스플로잇(exploit), 컴퓨터 보안 업계에서 사용하는 용어로, 취약점 또는 이를 공격하는 것을 말한다. 단순하게 말하면 해킹. [5] 원문은 our proof-of-concept exploit. 발견한 버그를 활용하여 공격을 가할 수 있음을 보이는 실증 테스트용 코드를 의미한다. [6] 들고 있는 나뭇가지는 분기 예측 실행(branch-prediction execution)을 뜻한다. [7] 그 중에서도 cache-timing Attack에 해당한다. [8] 현재까지 발견된 건 A15, A57, A72, A75인데, A57 단독으로만 봐도 100만 대 이상의 스마트폰이 취약점에 노출되어있는 상황이다. A57은 퀄컴 스냅드래곤 808과 스냅드래곤 810, 삼성 엑시노스 7(5433)에도 들어갔다. [원문1] all modern processors capable of keeping many instructions in flight are potentially vulnerable [10] 여기에 명령어 디자인의 철학이 반영돼있음을 엿볼 수 있다. 정상적이라면 1번 명령을 실행하려면 <1번명령 접수> → <1번 명령 권한 체크> → <체크됨-명령 실행|체크 안됨-명령 중지>라는 순서로 돼야 한다. 하지만 이런 식으로 모든 명령에 대하여 권한 체크를 하게 된다면 순차적으로 진행해야 하고 그렇게 되면 시간이 늘어지게 된다. 그래서 생각해 낸 게 지금의 보안 결점의 핵심이다. <1번명령을 접수> → <1번명령 실행과 동시에 권한 체크> → <체크됨-숫자를 보여줌|체크 안됨-명령 중지>라는 순서로 되어 읽어 보여줄 때 벌써 캐시에(레지스터와 동일하고 읽기/쓰기가 가장 빠르다.) 불러와 있는 값을 주면 되기에 속도가 빨라진다. [11] 자세한 것은 메모리 계층 구조 참조. [12] 실제로는 캐시가 RAM에서 정보를 한 번에 가져오는 단위인 캐시라인을 고려해야 한다. 여기에서는 설명을 위해 단순화했다. [13] C가 실행되지 않았는데 D가 실행될 수 있는 이유는 파이프라인 구조에서 성능향상을 위해 실행이 완료되지 않은 명령어의 정보를 다른 명령어에게 전달할 수 있기 때문이다. [14] CPU클락 카운터 등 정밀한 시계를 사용한다. 읽기는 무작위로 해야 한다. 순서대로 읽을 경우 CPU에서 이를 예측하고 ua2의 일부 내용을 캐시에 미리 올릴 수 있다. [15] 함수 호출뿐 아니라 더 일반적으로 jmp와 같은 점프를 뜻한다. [16] 해당 문제 설명에서 PC에 물리적 접근이 필요하다는 말이 이것 때문이다. 처음부터 부팅 시의 셋업까지 원격으로 가능한 경우는 거의 없고, 설정에서 풀어 놓아야 한다. [17] 스카이레이크 아키텍처에 처음 추가된 기능으로, CPU 차원에서 다른 프로세스가 들여다볼 수 없는 격리된 영역을 메모리 안에 제공하는 기능이다. [18] 해결 여부는 스테핑에 따라 다를 수 있음 [커피R] 멜트다운/스펙터 해결 [커피R_일부] 멜트다운/스펙터 해결 [코멧] 멜트다운/스펙터 해결 [코멧] 멜트다운/스펙터 해결 [코멧] 멜트다운/스펙터 해결 [24] 일반 소비자용은 i9-9900부터, HEDT는 i9-10xxx부터 멜트다운/스펙터 해결 [25] 데스크탑 제품은 W-x2xx부터, 모바일 제품은 W-10xxx부터 멜트다운/스펙터 해결 [캐스캐이드] x2xx 넘버링부터 멜트다운/스펙터 해결 [휴잇] D-16xx 넘버링에서 멜트다운/스펙터 해결 [커피R_일부] 멜트다운/스펙터 해결 [코멧] 멜트다운/스펙터 해결 [30] 코어 아키텍처 기반의 E 시리즈와 웨스트미어 아키텍처 기반부터 현재까지의 G 시리즈가 이에 해당된다. [31] 애플 워치는 원천적으로 멜트다운과 스팩터 모두에 영향을 받지 않으며, 나머지 기기들은 17년 12월 6일에 멜트다운 버그 패치를 받았다. [32] 표와 번역 내용에 오류가 있으니 주의. [33] 단 자체 아키텍처로 변경하기 전의 모델은 똑같이 영향을 받는다. [34] 틀린 말은 아니다. 하지만 이번 이슈는 "데이터의 유출"이지 "데이터의 손상"이 아니라는 점에서 논점을 흐린 변명에 가깝다. [원문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] 내용을 보면 범용적인 보안 지침 안내이다. 이걸 안 지켜서 사달이 난 것이 불과 몇 개월 전에 벌어진 워너크라이 사태. 멀리 가보게 된다면 CIH 바이러스나 슬래머 웜, 블래스터 웜 등의 사례도 있다. [37] 연설문 전체는 여기에서 볼 수 있다. [38] 해당 기사에서 자화자찬 논란이 일고 있다고 했지만, 해외의 반응을 보면 보안 이슈와 사과가 없다는 것에 더 논란이 일고 있다. 이후 인텔 홈페이지에 올라온 기사를 보면, 크르자니크가 이러한 표현을 사용한 것은 자화자찬이라기보다는 보안 이슈를 발견해주고, 해결하기 위해 협력해준 업계에게 감사를 표하기 위해 사용한 것으로 보인다. [39] 더 자세한 내용은 여기에서 볼 수 있다. [원문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. 출처는 위에 적힌 발표 링크 [41] 출처 [42] 윈텔이라는 말이 있을 정도로 Microsoft Windows와 인텔은 서로 떼어놓을 수 없는 관계다. [43] 당시 마이크로소프트는 다른 운영체제는 1월 9일에 패치가 나올 거라고 했는데 이건 자동 업데이트 기준이었던 모양으로, 1월 4일에 다른 운영체제도 수동 업데이트는 나왔다. 1월 9일엔 윈도우 10 이외의 운영체제도 자동 업데이트로 업데이트가 된다. [44] 브라우저도 CPU 보안결함 대응 나섰다 [45] To be determined: '미정'을 의미하는 사무적 표현이다. [46] 윈도우 보안 업데이트, 2017년 11월 지원된 마이크로코드, 펌웨어 업데이트를 진행한 상태에서 그랬다. 그러나 새로운 펌웨어 업데이트 결과 모두 안전하게 나왔다. [A] LTSC(구 LTSB) 한정 [A] LTSC(구 LTSB) 한정 [49] 물론 서버환경에 IO만 영향을 주는 것은 아니기에 클라이언트 사용자 기준에선 체감이 없을 가능성도 있다. [50] 세이브, 스크린샷, 설정 변경 등 소수 기능은 쓰기를 이용하지만 이러한 작업은 전체적인 게임 진행 중 매우 일부분만 차지하기 때문에 별 상관이 없다. [51] 더 큰 문제는 보통 서버로 사용되는 CPU들은 6세대보다도 더 구형인 경우가 꽤나 많다는 점이다. 6세대인 스카이레이크만해도 이런데 그 이전 것들은 오죽할까? [52] 특히 당시 CEO였던 크르자니크는 인텔의 엔지니어 출신인데 그동안 한 일이 가관이다. R&D 예산 대폭 삭감, 엔지니어 대량 해고, 기존의 상품을 성능만 조금 올리거나 조금씩 바꾸어 비싸게 팔아먹음, CPU 문제를 알고도 8세대 커피레이크 출시, 그리고 문제를 은폐하고 자신이 소유하고 있는 주식중에서 팔 수 있는 수준의 자사 주식은 다 팔아 먹음. 정작 기가 막히게도 이 사건이 알려지기 전인 2017년 12월 포브스에서 '사내 복지 잘하는 CEO 1위'로 선정되기도 했다. [53] IT거인 큰코 다치나..인텔에 소비자 줄소송, 애플엔 벌써 26건 [54] 고든 무어. 1997년에 이사회의 회장직에서 은퇴하여 명예 회장이 되었다. [55] 인텔의 엔지니어 프랑수아 피에노엘 [56] 로버트 노이스, 폴 오텔리니. [57] Meltdown-RW, 원래 스펙터 유형 1.2로 정의했으나 Page Fault exception이 원인인 transient execution 취약점이므로 멜트다운으로 다시 정의했다. [58] 5.3 Evaluation of Defenses의 Meltdown Defense 항목 참조. 마지막 문장은 반대로 적은 것 같지만 그렇다고 실험 내용이 잘못되었다는 근거가 되지는 않음. [59] 실험 대상 CPU가 일부 CPU로 한정된 것일 뿐 설계 사상이 바뀌지 않았다면 기존 CPU에서도 취약점이 발견될 소지가 있는 것으로 보아야 할 것이다. 특히 AMD의 경우 E2-2000에서도 해당 취약점이 존재함을 증명하여 기존 CPU에서도 유효함을 간접적으로 설명하고 있다. 실험에 사용한 MPX 명령 셋의 경우 Intel의 최신 CPU에만 적용되므로 일부인 것이 맞으나 bound 명령의 경우 x86 CPU 전체가 다 포함된다. bound 명령은 64비트 환경에서는 동작하지 않지만 아직 32비트 호환 모드(Windows의 경우 WOW64를 통해 지원)는 여전히 많이 사용되고 있으므로 안심해서는 안 된다.