CPU 취약점 Meltdown(멜트다운)과 Spectre(스펙터)

CPU 취약점 Meltdown(멜트다운)과 Spectre(스펙터)

멜트다운과 스펙터는 구글 보안기술팀인 Project Zero 제인 혼 수석연구원과 오스트리아 그라츠 공과대학, 업계의
보안 전문가들에 의해 발견되었다.
구글은 2017년 6월 1일경에 인텔, AMD, ARM등 주요 CPU 제조사에게 이 버그의 존재를 알려주었다. 공개되기 전 패치를
통하여 조치를 취할 수 있도록 하기 위함이다. 이후 1월 3일 Project Zero 블로그를 통해 해당 버그를 공개하였다.

유형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은 멜트다운 취약점이다. 
유형 1과 2에 해당하는 스펙터 취약점은 한 유저 프로그램이 다른 유저 프로그램 메모리를 볼 수 있는 취약점이다.
유형 3인 멜트다운 취약점은 유저 프로그램이 OS 권한 영역을 훔쳐 볼 수 있는 취약점이다.

스펙터 취약점은 인텔, AMD, ARM 프로세서에서 발견되고, 멜트다운은 인텔 CPU와 일부 ARM Cortex(애플, 닌텐도 스위치등)
에서 발생하고 있다.
스펙터보다 멜트다운 취약점이 치명적인데, 멜트다운의 경우엔 모든 보안 정책이 무효가 되고 OS의 메모리 정보를
인가받지 않은 사용자가 읽을 수 있다.

스펙터는 CPU 속에 담겨 있는 수 많은 명령어에서 일어나는 버그를 악용한 보안 취약점으로 멜트다운보다 덜 치명적이고
구현하기도 어렵지만, 반대로 막는 것도 어렵다는 유령 같은 특징과 추측 실행(Speculative execution)의 어감을 이용하여
스펙터라는 이름이 붙었다. 
멜트다운은 CPU 마이크로아키텍처 구조에서 마이크로옵 단위에서 발생되는 레이스 컨디션 공격이다. 

CPU 마이크로 아키텍처 구조는 다음과 같다.

명령어(instruction)
CPU의 동작은 할 일을 적어놓은 명령어가 수행되면서 동작한다. 예를 들어 3개의 명령어를 순차적으로 실행한다고 하면,
(1) : x라는 값을 읽고, (2) : x에 1을 더하고, (3) x를 y에 저장하라로 설명할 수 있다.

파이프라인(Pipeline)
파이프라인은 CPU가 하나의 명령어를 처리하는 과정도 너무 복잡하고 많기 때문에, 이를 잘게 쪼개서 여러가지 작은
단계로 나누어 처리하는 방식이다. 파이프라인 단계는 나눈 방법이 여러가지가 있지만, 대체로 다음과 같이 8단계로
나눌 수 있다. 대부분의 명령어는 다음의 단계를 차례대로 진행한다.

(1) 호출 (Fetch) : 실행할 명령어를 주메모리에서 가져옴.
(2) 해독 (Decode) : 명령어가 어떤 것인지 해독.
(3) 재명명 (Rename) : 명령어가 쓸 물리 레지스터를 할당한다. 레지스터 EAX에 값을 저장하는 명령어이라면,
실행이 완료될 때까지 사용자에게 노출되지 않는 물리 레지스터에 값을 저장하고, 명령어가 최종적으로 완료되면
그때 값을 노출 시킨다.
(4) 디스패치(Dispatch) : 명령어가 재정렬 버퍼 (Re-Order Buffer, ROB)의 맨 뒤에 들어간다. 다음 단계인 송출 ->
실행 -> 회신까지는 나중에 온 명령어가 먼저 수행될 수 있는데 (Out-of-order execution), 최종적으로 명령어가
나갈 때는 원래 순서를 지켜서 유저는 순서가 바뀐 것을 알아챌 수 없게 하기 위해 ROB 맨 뒤에 명령어를 넣는다.
(5) 송출 (Issue) : 명령어가 실행단계에 필요한 자원이 준비되면 보낸다. 레지스터 EAX에 1을 더하는 명령어라면 일단
EAX의 최신 값을 만들어내는 이전 명령어가 아래의 회신 단계를 완료해야 한다.
(6) 실행 (Execute) : 명령어를 실제로 수행한다. 계산이나 주 메모리에서 값을 읽어오거나 처리하는 것이 이때
실행된다.
(7) 회신 (Writeback) : 전송완료신호를 보내는 것. 만들어진 결과 값을 재명명(Rename) 단계에 할당 받은 물리
레지스터에 저장한다. 이 값을 기다리던 명령어들에게도 알려준다.
(8) 완료 (Commit) : 사용자에게 노출되지 않은 물리 레지스터를 사용자에게 노출시킨다.

※위의 과정에서 특이한 점은 어떤 명령어가 완료되기 전까지는 사용자에게 명령어 수행의 결과를 노출시키지
않는다는 것이다. 어떤 이유로 명령어 수행을 취소해야 하면, 잘못 수행된 명령어중 가장 오래된 것부터 시작해서
이후 모든 명령어를 파이프라인에서 지운다. 이런 상황은 미연에 방지하는 것이 좋겠지만, 피할 수 없는 이유는
추측실행(Speculative execution)때문이다.

캐시(Cache)
주 메모리에서 값을 읽는 동작은 CPU의 처리 속도에 비해 매우매우매우 느리다. 따라서 이 차이를 줄이기 위해 매우
빠르지만, 작은 저장 공간이 CPU에 있는데, 이를 캐시(Cache)라고 한다. 캐시는 공간이 작기 때문에 새로운 값을
읽어들이려면 기존 값을 다시 원래 위치로 돌려보내야 하는데, 주로 가장 오래된 값을 돌려보낸다. 이는 최근에
접근한 값이 또 접근할 가능성이 높은 성질과 어떤 값을 읽으면 그 근처의 값을 읽을 확률이 높은 성질을 이용한 것이다.
(참조지역성, Principle of locality) 이렇게 캐시에 값이 들어오는 덩어리를 캐시 라인이라고 하며, 보통 64바이트의 크기를
가진다. 구체적으로 메모리 주소를 64로 나누었을 때 몫이 같은 데이터들은 한 캐시 라인을 구성하게 된다.

분기 예측(Branch prediction)
분기 (Branch) 명령어는 어떤 조건이 맞으면 다음에 실행할 명령어의 위치를 임의로 지정할 수 있게 한다. 이는 같은
명령어들을 반복해서 실행하거나 조건에 따라 다른 일을 하고 싶을 때 사용하는 기본적인 명령어이다. 다만
분기(Branch) 명령어는 파이프라인에서 한가지 문제를 일으킨다.
(1) 분기(Branch)가 가르키는 주소로 이동할지 안할지
(2) 이동하는 주소가 어디인지 알아내는 것은 해독(Decode)나 실행(Execute)단계가 와야한다.
다음 명령어 위치를 마냥 기다리자니 파이프라인의 호출(Fetch)단계가 놀게 된다. 이를 막고자 다음 명령어 위치를
예측하는 기법을 사용하는데, 이것이 분기 예측(Branch prediction)이다. 당연히 가르키는 주소로 갈지 안갈지의 방향
예측과 가르키는 주소 자체의 예측 두 가지가 함께 이루어진다.

비순차적 명령어 처리 (Out-of-Order Execution, OoOE)
비순차적 명령어 처리(OoOE)는 파이프라인의 송출 -> 실행 -> 회신 단계에서 늦게 온 명령어가 일찍 온 명령어보다
먼저 처리 할 수 있는기능이다. 앞에 온 명령어의 처리가 수행될 수 없지만 뒤에 온 명령어는 수행할 수 있는 경우가
있는데, 그러면 CPU를 놀게 하기보다 뒤에 온 명령어를 먼저 처리하자는 의도이다. 당연히 아무 때나 할 수 있는 것은
아니다.
이렇게 순서를 바꿔도 사용자가 보는 값이 비순차적 명령어 처리(OoOE)를 하지 않았을 때와 같은 경우에만 할 수 있다.
까다로운 조건 체크때문에 비순차적 명령어 처리(OoOE)를 달면 속도는 빨라지지만 칩이 커지고 전기도 많이 쓰인다.
초창기에는 휴대기기용 CPU엔 비순차적 명령어 처리(OoOE)가 없었다가 최근에 최적화를 거친 뒤 사용되기 시작했다.

추측 실행(Speculative execution)
완료(Commit)단계 전에는 명령어 수행을 취소할 수 있다. 그러므로, 어떤 명령어가 특정 파이프라인 단계에 필요한
정보가 없어서 진행이 막혔을 때, 필요한 정보를 예측해서 높은 확률로 맞춘다면 틀렸을 때의 다소 큰 손해를 넘어서는
이익을 취할 수 있다. 고성능의 CPU는 이러한 예측에 기반한 기술들을 활용하고 있다.
반복문이 있다고 하자. 이 반복문의 맨 마지막 명령어는 종결 조건이 맞지 않는 동안 반복문의 맨 처음 명령어로
점프하도록 만들어져 있다. 결과적으로 마지막 반복 말고는 항상 맨 처음 명령어로 점프하기에 높은 확률로 점프를
한다는 예측이 맞게 된다. 이렇게 예측을 하면 굳이 마지막 명령어를 실행(Execute)할 필요도 없이 다음 명령어를
호출 (Fetch)할 수 있고, 기다리는 시간을 줄여서 성능을 대폭 상승시킨다. 다만 맨 마지막 반복에서도 예측을 통하여
반복을 할려다가 틀리게 된다. 예측이 틀린지 아는 시점은 명령어의 해독(Decode) 혹은 실행(Execute) 단계 수행
직후이며, 틀렸다면 틀린 명령어의 완료(Commit)단계 때 자기 자신과 이후 호출(Fetch)된 모든 명령어를
파이프라인에서 지우게 된다.

스펙터

스펙터는 추측 실행(Speculative execution)이 실행 할 때 다른 곳의 코드 실행[분기표적주입 (branch target injection)의
경우]이나 조건문[경계검사 우회(bounds check bypass)의 경우]을 실행한 뒤 잘못된 경우 실행을 취소시키는데,
이 때 발생한 부작용을 악용하여 다른 프로그램의 메모리를 읽는 것이다.
다만 메모리를 훔쳐볼 수만 있고 메모리에 기록할 수 없으므로 그 자체만으로 직접 시스템에 파괴적인 행동을 하거나
악성코드를 심는 것은 불가능하다. 또한 커널 영역에 접근 가능한 것이 아니므로 상대적으로 멜트다운보다는 영향이
좀 더 작을 것이다. 하지만 다른 프로세스의 메모리에 올라온 모든 정보를 해커가 읽을 수 있는 이상, 정보가 유출될
가능성은 있다. 
스펙터의 경우 유저들의 프로그램간 메모리 스니핑이 일어나는거지만, 기본적으로 대상 프로그램에서 문제가 존재하는
코드의 추측 실행(Speculative execution)이 실행되어야 하기 때문에, 실제로 스펙터를 사용해 공격하려면 공격하려는
대상 프로그램을 세세하게 분석해야 되고, 프로그램이 돌아가는 아키텍처나 OS를 자세히 알아야 해서 실제로 공격하긴
매우 어렵다. 다만 어느 코드에서나 문제가 존재할 가능성이 있기 때문에, 문제를 발견해도 막기가 힘들 수 있다. 
프로세서는 일부 조건 분기, 예를 들어 if else가 성립되지 않는 상황 등에서 먼저 해당 조건 안에 있는 코드를 실행하며,
발생 조건이 맞지 않는다면 해당 결과를 버리게 된다. 
스펙터 취약점은 이러한 특성을 이용하여 CPU가 분기가 맞는지 안맞는지 판단하기 전에 분기 내부에 포함되어 있는
코드(공격자가 악의적인 목적으로 작성해놓은 코드)를 실행한다면 결과적으로 일부 데이터가 L1 cache에 저장된다.
그 이후 이 데이터에 접근한 시간을 통해 어떠한 케시에 저장되어있는지 추측하고, 다시 역순으로 실행을 통해
자신의 메모리 경계를 넘어 메모리를 읽어올 수 있다.

spectre.exe

spectre-attack-master.zip

<리눅스>

<윈도우 / i5-5200U>

위의 프로그램은 스펙터 논문에서 게시된 소스를 그대로 컴파일한 내용이다. 

멜트다운

최신 CPU들은 처리 속도를 조금이라도 더 향상시키기 위해 여러 기술들을 도입하였다. 그것들 중에 이번 멜트다운과
관련된 기술은 예측실행(Speculative Execution)과 분기 예측(Indirect Branch Preddiction)기술이다.
이 기술은 약 20년 전(1995년)부터 사용되기 시작하였다. 프로세서는 한가지 명령에 대한 처리가 끝나면 다른 명령을
받기 전까지 어떠한 작업도 하지 않는다. 하지만 최적화 기술이 적용된 프로세서들은 명령을 받지 않아도 다음에 실행될
명령들을 예측하여 해당 명령을 처리하기 위해 필요한 데이터들을 CPU캐시에 로드해 놓는 방법을 통해 CPU성능을
향상 시켰다.

<정상적인 프로세스 과정>

CPU마이크로 아키텍처, 파이프라인 설명했듯이 이 과정에서 컴퓨터가 올바르게 예측하여 예측한 명령이 처리된다면
CPU속도는 빨라지겠지만, 잘못 예측하면 해당 작업을 취소하고 예측 전의 단계로 돌아간다.
파이프라인은 예측 전의 상태로 돌아가지만, 예측한 명령을 실행하기 위해 CPU캐시에 로드해놨던 데이터들은
여전히 남아있게 된다.

<프로세스 과정 중 오류 발생>

예측실행 기능을 가진 CPU의 실행과정 중, 명령 4가 필요한 메모리 로드 사이클은 명령 3이 정상적으로
실행되었는지와는 상관 없이 예측하여 메모리 캐시에 로드시켜놓는다. 이 과정에서 메모리의 적합성 여부는 판단하지
않는다. 위에 설명했다시피, 명령 3의 예측과정에서 오류가 발생하면, 명령4는 실행되지 않지만, 명령 4를 수행하기 위해
필요한 데이터들은 이미 CPU캐시에 로드되어 있는 상태이다. 이렇게 CPU 캐시에 로드되어 있는 데이터들 중에
관리자 권한으로만 접근이 가능한 데이터들도 포함되어 있을텐데, 이 때 로드되어 있는 메모리들에 비정상적으로
접근하거나 권한이 없는 사용자가 접근을 하여도 모두 허용하게 된다.
그 이유는 CPU는 CPU 캐시에서 레지스터로 전송하기까지 일련의 메커니즘을 통해 주소의 적합성 여부를 판단하는데,
CPU 분기 예측 과정에서 오류가 발생하였고, CPU 캐시메모리로의 로드까지만 실행되었으며, 레지스터로의 전송 과정이
완료되지 않았기 때문에, 해당 케시 메모리에 대한 비정상적인 접근을 모두 허용하게 된다.
멜트 다운은 인텔의 경우 microarchitectural을 타겟으로 하는 공격으로, 비 순차적인 실행 방법을 이용하는 사용자의
커널 메모리를 유출 시킬 수 있다. 
공격자는 멜트다운 취약점을 이용해 프로세서에 있는 권한 상승 취약점을 공격한다. CPU의 추측 실행 기능을 이용하면
공격자가 메모리 보호를 우회할 수 있기때문이다.
해당 취약점을 이용하면 사용자 공간에서 커널 메모리에 접근하도록 허용한다. 이는 사용자가 시스템 내부에 존재하는
보안 메커니즘을 우회하여 정보를 유출시킬 수 있다.

<Spectre and Meltdown for Dummies>

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

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

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

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

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

다음은 깃허브에 있는 멜트다운 POC 데모 설명이다. 
(깃허브 주소 : https://github.com/IAIK/meltdown/)

이 깃허브에는 다양한 사용 사례를 보여주는 5가지 데모가 있다. 깃허브에서 실행한 데모는 Intel Core i7-6700K를
사용하며 Ubuntu 16.04에서 테스트되었다. 2010년부터 최신 Intel cpu를 사용하는 모든 linux에서 작동될 수 있다.
(필자는 가상머신/우분투 16.04으로 진행)
최상의 결과를 얻고 싶다면 인텔 TSX를 지원하는 CPU를 사용하는 것이 좋다. 그리고 모든 데모는 하나의 cpu 코어에
고정되어 있어야한다. 

Build dependency for demo

데모 시연을 위해 먼저 glibc-static이 설치되어 있어야한다.

>> apt-get install -y glibc-static

Demo #1 : A first test (test)

가장 기본적인 데모이다. 멜트다운을 이용해 메모리 경계선을 넘지 않는 자체 주소 공간에서 엑세스 가능한 주소를 읽는다.
만약 이 데모가 동작하지 않는다면 나머지 데모도 동작하지 않을 가능성이 높다. CPU가 느려서 OoOE가
동작안할 수 있고, 타이머가 정확하지 않거나(가상 머신) OS가 지원하지 않는 등 다양한 이유가 있다.

Build and Run

>> make
>> taskset 0x1 ./test

만약 다음과 같은 출력이 나온다면 기본적인 데모는 동작하는 것이다.
Expect : Welcome to the wonderful world of microarchitectural attacks
    GOT: Welcome to the wonderful world of microarchitectural attacks

Demo #2 : Breaking KASLR (kaslr)

리눅스 커널 4.12부터는 KASLR(Kernel Address Space Layout Randomization)이 기본적으로 활성화되어 있다. 즉,
재부팅할 때마다 커널 위치가 변경된다. (uname -a로 커널 버전 확인 가능)
이 데모에서는 멜트다운을 이용해 직접 물리적 주소가 무작위로 바뀌는 것을 무효화한다. 이 데모에서는 프로세스의
속도를 높이기 위해 루트 권한이 필요로 한다. 논문에서는 루트 권한이 필요없다.

>> sudo taskset 0x1 ./kaslr

몇 분뒤 아래와 같은 출력을 확인 할 수 있다.

Demo #3 : Reliability test (reliability)

이번 데모는 얼마나 신뢰성있게 물리 메모리를 읽을 수 있는지 테스트 하는 데모이다. 이 데모에서 물리적 메모리
오프셋이 있거나, 커널에서 KASLR을 비활성화 해야 한다,
KASLR을 비활성화 시키지 않았다면 Demo #2에 있는 값을 가져오고, 비활성화 시켰다면 매개 변수를 안넣어도 된다.

>> sudo taskset 0x1 ./reliability 0xffffaeb100000000

Demo #4 : Read physical memory(physical_reader)

이 데모는 실제 메모리를 직접 읽음으로 다른 프로세스가 사용하는 메모리를 읽는다. 이 데모에서는 물리적메모리 오프셋
이나 KASLR을 비활성화 해야한다.

>> sudo ./secret 

secret을 실행시켜둔 채로 physical_reader를 실행시킨다. 첫 번째 매개변수는 secret에 실행된 주소이다. 두 번째
매개변수는 물리적 메모리 오프셋이다. 이전 데모와 마찬가지로 KASLR을 비활성화 하면 필요없다.

>> taskset 0x1 ./physical_reader 0x3accd62 0xffffaeb100000000

몇 분 뒤 결과가 나올 것이다.

Demo #5: Dump the memory (memdump)

메모리 내용을 덤프뜹니다. 이전 데모 #3, #4와 마찬가지로 물리적메모리에 있는 값을 16진수 형식으로 덤프뜹니다.
물리적 메모리에는 사람들이 읽을 수 없는 많은 내용이 포함되어 있습니다. 우리는 사람들이 읽기 편하게 문자열을
채워주는테스트 도구를 제공한다.

시연에 앞서 사람이 읽을 수 있는 문자열로 메모리를 채우기 위해 memory_filler를 실행한다. 첫번째 매개변수는 채울
메모리 양(기가바이트)이다.

>> ./memory_filler 1

그리고 메모리 내용을 덤프하기 위해 memdump를 이용한다. 이전에 memory_filler를 실행한경우 문자열 일부가
나타난다. 실행중인 인터넷 익스플로러가 있는 경우, 웹 열려있거나 최근에 닫은 익스플로러를 볼 수 있다.

첫번째 매개변수는 덤프가 시작되어야 하는 실제 주소이다.(첫번째 기가바이트에서 실행하려면 빈칸)
두번째 매개변수는 읽으려는 바이트 수이며, 읽을려면 -1이다. KASLR를 비활성화 하지 않았다면 세번째 매개변수는
물리적 메모리 오프셋이다.

>> taskset 0x1 ./memdump 0x240000000 -1 0xffffaeb1000000

. 밖에 안나왔다. 계속 돌리면 유의미한 정보를 얻을 수 있을거라 판단된다.

멜트다운과 스펙터 차이점

	멜트다운	스펙터
아키텍쳐	인텔, 일부 ARM	인텔,ARM,ADM
엔트리	해당 시스템에서 코드실행	해당 시스템에서 코드실행
메서드	인텔 권한 상승 + 예측 실행	브랜치 예측 + 예측 실행
영향	사용자 공간에서 커널 메모리 읽기	프로그램 실행하는 다른 사용자로부터 메모리 읽기
대응	소프트웨어 패치	소프트웨어 패치

※ 소프트웨어 패치가 100% 막을 수 있는 것은 아니며, "완화"한 것이라고 볼 수 있음. 패치시 성능 저하 및 호환 문제가
발생가능성이 있음.

동적분석

http://blog.alyac.co.kr/1481?category=957259

자바스크립트 기반 Spectre 취약점 코드

var TABLE1_STRIDE = 1;
var TABLE1_BYTES = 3;
var probeTable = ['alpha', 'beta', 'corky'];
var simpleByteArray = [0x00, 0x01, 0x02];
var localJunk;
var index = 0;
if (index < simpleByteArray.length) {
    index = simpleByteArray[index | 0];
    index = (((index * TABLE1_STRIDE) | 0) & (TABLE1_BYTES - 1)) | 0;
    localJunk &= probeTable[index | 0] | 0;
}
console.log(localJunk);

공격 탐지를 위한 SNORT RULE

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"ET WEB_CLIENT Spectre Kernel Memory Leakage JavaScript (POC Based)"; flow:established,from_server; file_data; content:"<script"; content:"|3c 20|simpleByteArray.length|29|"; distance:0; content:"simpleByteArray|5b|"; within:50; content:"|2a 20|TABLE1_STRIDE|29 7c 30 29 20 26 20 28|TABLE1_BYTES-1|29|"; distance:0; fast_pattern; content:"|5e 3d 20|probeTable|5b|"; distance:0; content:"|7c 30 5d 7c 30 3b|"; distance:0; metadata: former_category WEB_CLIENT; reference:url,spectreattack.com/spectre.pdf; classtype:attempted-user; sid:2025184; rev:2; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Client_Endpoint, deployment Perimeter, signature_severity Major, created_at 2018_01_04, updated_at 2018_01_04;)  alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"ET WEB_CLIENT Spectre Kernel Memory Leakage JavaScript"; flow:established,from_server; file_data; content:"<script"; nocase; content:"<"; distance:0; content:".length"; distance:0; nocase; fast_pattern; pcre:"/^\s*?\)\s*?\{\s*(?P<var>[^\s]+)\s*=[^\x5b]+?\x5b\s*(?P=var)\s*?\|\s*?0\s*?\]\s*?\x3b\s*?/Rsi"; content:"^="; distance:0; pcre:"/^\s*[^\s]+\x5b\s*?[^\x5d\x7c]+\x7c\s*?0\s*?\x5d\s*?\x7c\s*?0\s*?\x3b/Rsi"; metadata: former_category WEB_CLIENT; reference:url,spectreattack.com/spectre.pdf; classtype:attempted-user; sid:2025185; rev:2; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Client_Endpoint, deployment Perimeter, signature_severity Major, created_at 2018_01_04, performance_impact Low, updated_at 2018_01_04;)

취약점 관련 패치 대응 상황 

- Intel Security Advisory https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr - ARM Trusted Firmware Security Advisory TFV 6 https://github.com/ARM-software/arm-trusted-firmware/wiki/ARM-Trusted-Firmware-Security-Advisory-TFV-6 - NVIDIA Security Notice http://nvidia.custhelp.com/app/answers/detail/a_id/4609 - IBM POWER 칩 관련 펌웨어 및 리눅스 패치 적용 https://www.ibm.com/blogs/psirt/potential-impact-processors-power-family/ - MS Windows 패치 적용 https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV180002   (1) MS Windows Server 패치 적용 https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution   (2) MS Windows 패치 적용(2018년 1월 Windows 운영체제의 보안 업데이트 적용)        * 안티바이러스와 호환성 주의 (하단 안티바이러스 대응 상황 꼭 참고 바랍니다.) https://support.microsoft.com/ko-kr/help/4072699/important-january-3-2018-windows-security-updates-and-antivirus-softwa   (3) Windows 패치 적용 위해서는 위 안티바이러스 호환성 확인 및 호환되는 버젼으로 업그레이드 후, 아래와 같은 Registry 값이 설정되어 있어야 합니다. Key="HKEY_LOCAL_MACHINE" Subkey="SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat" Value="cadca5fe-87d3-4b96-b7fb-a231484277cc" Type="REG_DWORD” 이 값에 대한 설정을 도와 주기 위해 이스트소프트에서 제작 공개한 레지스트리 자동 수정 유틸(AllowMeltdownPatch.exe)을 첨부파일로 추가하였습니다. 참고 바랍니다. - XenServer 7.1, 7.2, 7.3 Hotfix 설치(7.0은 아직 패치 작업 중) https://support.citrix.com/article/CTX231390 - VMWare 패치 적용 https://www.vmware.com/us/security/advisories/VMSA-2018-0002.html - Hyper-V 관련 보안 가이드  https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/CVE-2017-5715-and-hyper-v-vms - Amazone Linux 커널 업데이트 https://alas.aws.amazon.com/ALAS-2018-939.html   * 그외 Amazone 서비스에 대한 관련 업데이트 사항 https://aws.amazon.com/ko/security/security-bulletins/AWS-2018-013/ - SUSE Linux 커널 업데이트 https://www.suse.com/support/kb/doc/?id=7022512 - RedHat Linux 커널 업데이트(CetOS 포함)  https://access.redhat.com/security/vulnerabilities/speculativeexecution - Ubuntu 커널 업데이트 https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown - Fedora 커널 업데이트: Fedora 26, 27(커널 버젼 4.14.11 이상), Rawhide(커널 4.15 이상) https://fedoramagazine.org/protect-fedora-system-meltdown/ - Debian 커널 업데이트: 4.9.65-3+deb9u2 이상  https://security-tracker.debian.org/tracker/CVE-2017-5754 - FreeBSD (커널 업데이트 예정 확정 안됨) https://www.freebsd.org/news/newsflash.html#event20180104:01 - CISCO (2월 18일 패치 예정) https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180104-cpusidechannel - DELL 패치 적용 http://www.dell.com/support/article/kr/ko/krdhs1/sln308587/microprocessor-side-channel-attacks--cve-2017-5715--cve-2017-5753--cve-2017-5754---impact-on-dell-products?lang=en - HP 패치 적용 https://support.hp.com/kr-ko/document/c05869091 http://h22208.www2.hpe.com/eginfolib/securityalerts/SCAM/Side_Channel_Analysis_Method.html - MS SQL Server 관련 보안 가이드 https://support.microsoft.com/en-us/help/4073225/guidance-for-sql-server - 화웨이 (패치 일정 미정) http://www.huawei.com/au/psirt/security-notices/huawei-sn-20180104-01-intel-en - F5 https://support.f5.com/csp/article/K91229003 - Fortinet https://fortiguard.com/psirt/FG-IR-18-002 - Juniper https://kb.juniper.net/InfoCenter/index?page=content&id=JSA10842&actp=METADATA - NetApp https://security.netapp.com/advisory/ntap-20180104-0001/ - 애플 패치 적용 https://support.apple.com/ko-kr/HT201222 - 크롬 브라우저(수정 버젼 Chrome 64 - 1월 23일 발표 예정) * Site Isolation 기능 사용 권장    http://www.chromium.org/Home/chromium-security/site-isolation - 파이어폭스 브라우저 57 이상 업그레이드 권장 * 그외 패치 목록 검색 참고 https://exchange.xforce.ibmcloud.com/collection/Spectre-Meltdown-Vendor-Reference-List-d2b6dc11cff7409049c2ecb4a66a1103

윈도우즈 패치 적용에 따른 안티바이러스 대응 상황

   - 시만텍 (ERASER Engine 117.3.0.358 이상 패치) https://support.symantec.com/en_US/article.TECH248545.html

   - 안랩 V3 패치 적용  http://www.ahnlab.com/kr/site/support/notice/noticeView.do?boardSeq=50125159

   - 하우리 패치 적용 https://www.hauri.co.kr/security/notice_view.html?intSeq=465&page=1

   - 알약 패치 적용 (개인용 1월 10일, 기업용 1월 11일) https://www.estsecurity.com/securityCenter/news/view/1420

   - 비트디펜더 https://www.bitdefender.com/consumer/support/answer/9033/?icid=overlayccom_all_pagesmicrosoft_security_update_01_2018

[출처] Meltdown과 Spectre CPU 취약점 대응 정리 (SecurityPlus) |작성자 mirrk

※ 현재 인텔에서 보안패치시 문제가 발생해 업데이트를 보류해달라는 기사가 나왔다.

http://news.naver.com/main/read.nhn?mode=LSD&mid=shm&sid1=105&oid=003&aid=0008407950

참고

http://www.dailysecu.com/?mod=news&act=articleView&idxno=27795

http://www.bodnara.co.kr/bbs/article.html?num=144500

http://blog.alyac.co.kr/1472

http://blog.alyac.co.kr/1481?category=957259

http://bbs.ruliweb.com/news/board/1003/read/2146546

https://spectreattack.com/spectre.pdf

http://quasarzone.co.kr/bbs/board.php?bo_table=qf_cmr&wr_id=57044

https://googleprojectzero.blogspot.kr/2018/01/reading-privileged-memory-with-side.html

http://blog.yunochi.co.kr/?p=1230

http://cafe.naver.com/securityplus/25116

http://it.donga.com/27265/

https://namu.wiki/w/CPU%EA%B2%8C%EC%9D%B4%ED%8A%B8#s-3.2

https://github.com/Eugnis/spectre-attack

https://github.com/IAIK/meltdown/

http://blog.alyac.co.kr/1496

http://sata.kr/entry/%EB%B3%B4%EC%95%88-Issue-Intel-CPU-%EC%82%AC%ED%83%9C%EC%9D%98-Meltdown%EB%A9%9C%ED%8A%B8%EB%8B%A4%EC%9A%B4-Spectre%EC%8A%A4%ED%8E%99%ED%84%B0-%EC%B7%A8%EC%95%BD%EC%A0%90%EC%9D%84-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90

http://udteam.tistory.com/73

[출처] Meltdown과 Spectre CPU 취약점 대응 정리 (Security