CPU Meltdown & Spectre 취약점 2 (in 2022)

 

이어서 말을 옮기자면, 일단 쓰기에도 캐쉬가 적용되는 것은 맞기 때문에, 단순한 쓰기만으로는 캐쉬가 탈락되지 않는다. 하지만 Prime 공격이 기존 공격과 다른 점은 Prime + Probe를 사용한다는 것 외에 하나가 더 있는데, 그건 공격자와 공격대상이 다른 코어에 위치해야 한다는 점이다.

즉, 같은 코어에서 공격자와 공격대상 프로세스가 작동하고 있다면 이 방법은 통하지 않는다.

또한, 공격 기법을 설명하면서 ‘캐시’라고 대강 설명을 하였지만, 정확하게 말하면 각 코어에서 독립적으로 사용하는 L1, L2 캐시이며, 모든 코어가 공유하는 L3 캐시는 해당 사항이 없다. 참고로 기존 공격 방식에서는 어떤 캐시든 상관이 존재하기만 하면 데이터 유출이 가능하다.

스카이레이크의 캐시구조에서도 마찬가지로 L3 캐시는 공유되며, L2는 각 코어에 종속되어 있다.

각 코어가 독립적으로 캐시를 갖는다는 것은 하나의 CPU 내 동일한 메모리에 대한 캐시 사본이 여러 개 존재할 수 있다는 것인데, 만약 코어 1이 메모리 A에 대한 캐시를 가지고 있고 코어 2도 동일한 메모리 A에 대한 캐시를 가지고 있다면 반드시 이 두 캐시는 같은 내용이어야 한다. 당연하지만 이 두 캐시의 내용이 달라진다면 멀티코어 시스템은 제대로 작동할 수 없다. 이것을 캐시의 일관성(Cache Coherenct)이라 한다. 각 코어는 메모리에 쓰기 전 자신이 해당 메모리에 쓰기 권한을 획득하고자 한다는 것을 브로드캐스트하고, 이 메시지를 받은 코어들은 대상이 되는 메모리의 캐시를 가지고 있을 경우 이를 무효화한다. 이후 실제 메모리에 쓰면서 해당 코어의 캐시는 업데이트 되지만, 그 외 코어의 캐시는 모두 무효화된다. 이 캐시는 CPU 내 유일한 캐시가 되고 일관성은 지켜진다. 바로 이것이 쓰기 요청으로 인한 캐시 탈락이다.

그러면 Prime 공격이 기존 공격 방식과 어떤 차이가 있냐에 대한 생각을 해볼 수 있는데 이 공격은 기존의 Meltdown이나 Spectre를 성능 면에서 좀 더 최적화를 한 것이다.

캐시와 메모리는 수십 배 이상 속도 차이가 나기 때문에 캐시에 메모리의 내용이 없는 경우 이를 읽어서 적재하려면 캐시에서 바로 읽는 것보다 훨씬 많은 시간이 걸리게 된다. 그런데 어떤 종류의 메모리 쓰기 작업도 일단 캐시에 적재한 후 실메모리로 전달되므로(Write back 현재 CPU는 모두 Write back을 사용한다.) 메모리 write 작업은 캐시에 쓰는 것만으로 끝나고, 캐시가 넘치는 상황이 발생하지 않는 이상 Read 보다 항상 빠르다. 즉 추측실행에서 읽기를 하는 것보다 쓰기를 하는 것이 더 빠르기 때문에, 매우 짧은 Misspeculation window 내 공격을 마쳐야 하는 공격자 입장에서는 쓰기가 더 효율적인 공격방식이라는 결론을 내릴 수 있다.

실제로 해당 논문에서 테스트한 결과를 보면 동일한 HW에서 Spectre 취약점이 97.9% 확률로 공격에 성공한데 비해 SpectrePrime은 99.95%로 상당히 성공률이 개선되었다는 사실을 확인할 수 있다.

물론 공격자와 공격대상이 각각 다른 코어에 pin되어야 한다는 추가적인 조건이 있기 때문에 필드에서는 범용성이 떨어질 수 밖에 없다고 생각된다. 하지만 이런 방식의 공격 효율이 향상된다면, 향후 이 취약점들에 대해 안전하다고 알려진 CPU들에 대해서도 공격이 성공하는 사례가 나올지도 모른다.

Meltdown 참고

ARM Cortex-A15, Cortex-A57, Cortex-A72에서 작동하는 마지막 공격의 변형

Variant 1: Bounds Check Bypass, CVE-2017-5753 (Spectre)

Variant 2: Branch Target Injection, CVE-2017-5715 (Spectre)

Variant 3: Rogue Data Cache Load, CVE-2017-5754 (MeltDown)

SubVariant 3a : Privileged register reads from unprivileged code (MeltDown)

Meltdown 취약점의 대응

MeltDown은 일단 1) exploit을 대상 시스템에 업로드할 수 있어야 하고 2) 해당 exploit을 실행할 수 있어야 한다라는 두 가지 조건만 충족하면 공격이 성립한다.

즉 예전에 문제가 되었던 SMB attack처럼 네트워크에 접속만 하면 감염되는 그런 종류는 아니고 local exploit에 해당한다고 할 수 있다. 하지만 다른 종류의 공격을 통해 쉘(예를 들어 웹쉘)을 얻으면 앞서의 두 가지 조건은 아주 간단하게 맞춰지므로 네트워크로부터의 공격에 완전히 안전하다고 말할 수도 없다. 심각한 점은 이 취약점의 원리가 대단히 심오한데 비해 공격 방법이 간단하고 조건을 맞추기가 까다롭지 않기 때문에 패치가 되지 않은 시스템에 대한 공격은 아주 높은 확률로 성공한다는 것이다. 암호화된 비밀도 결국은 사용하기 위해 복호화해 메모리에 올려야 하는데, 이 부분을 아무런 흔적도 남기지 않고 쉽게 읽을 수 있다는데 MeltDown의 심각성이 있다.

또한 이 경우 1차적인 공격대상이 되는 건 커널 메모리이지만 커널 메모리에는 프로세스의 페이지 테이블이 저장돼 있다. 잘 알려진 대로 현대적인 CPU에서는 메모리를 유연하게 사용하기 위해 모든 주소를 가상화하여 사용하며 이 가상화된 메모리와 실제 물리 메모리를 맵핑하는 데이터를 갖는 것이 페이지 테이블이다. 즉 이 페이지 테이블이 없이는 메모리로부터 1바이트도 읽을 수 없는데 커널 메모리에 제한 없이 접근할 수 있다는 것은 곧 다른 프로세스의 메모리도 동일하게 읽어낼 수 있다는 사실을 의미하는 것이다.

따라서 위의 두 가지 조건을 충족하거나 그럴 가능성이 있는 시스템들은 패치를 해야 하며, 커널에 대한 공격이므로 OS에 대한 패치가 이 취약점에 대한 대응방법이 된다. 패치의 내용은 간단하게 커널의 페이지 테이블과 애플리케이션의 페이지 테이블을 분리하여 실제로 보호된 메모리의 내용은 커널이 아니면 읽지 못하게 하는 것이다. 리눅스에서는 이미 KPTI(Kernel Page Table Isolation)이라는 이름으로 적용돼 있으며, 윈도우의 패치도 페이지풀을 복사하는 유사한 내용이다. 지금까지는 효율을 위해 모든 애플리케이션의 페이지 테이블에 커널의 페이지 테이블을 복사해서 포함시켜 두었다. 결국 애플리케이션이 시스템콜을 하게 되면 커널의 주소공간에 위치한 API 함수들에 접근해야 하기 때문이다. 이번 패치는 애플리케이션과 커널이 컨텍스트 스위칭을 할 때 양쪽의 페이지 테이블을 그때마다 복사해서 교체하므로 애플리케이션에서 MeltDown 취약점을 이용해 커널주소의 내용을 읽으려고 해도 그에 해당하는 페이지 테이블이 없어서 실제 내용을 읽지 못하게 하는 것이다.

멀티테넌트와 Meltdown

멀티테넌트 시스템, 즉 많은 고객(테넌트)이 하나의 서비스나 시스템을 공유하는 경우 meltdown은 매우 위협적이라 말할 수 있다. 해당 공격 대상인 커널을 공유하는 시스템이라면 상호 간에 공격으로 인한 정보유출이 가능해지기 때문이다. Webhosting, Container, Para-Virtualization(반가상화) 기술을 사용하는 VM 등이 대표적으로 커널을 공유하는 서비스인데 이 서비스들은 모두 파일을 업로드하기 위한 공간과 작업을 하기 위한 쉘접속을 제공하므로 앞서 언급한 meltdown 공격이 성립하기 위한 조건 두 가지를 간단하게 충족해버린다. 즉 웹호스팅 계정을 하나 신청해서 쉘을 얻으면 그 서버에 접속하는 모든 다른 고객들의 정보를 얻을 수 있는 가능성이 존재한다.

따라서 이런 종류 서비스나 시스템이라면 성능 패널티를 감수하고라도 KPTI 패치는 필수적으로 해야 하는 것이다.

또 이런 멀티테넌트의 대표적인 서비스로 인프라 클라우드(IaaS)가 있는데, IaaS의 경우 멀티테넌트는 맞지만 일부 초기 버전 서비스를 제외한 대부분의 업체들이 하드웨어적으로 지원되는 전가상화(Full-Virtualization) 기술을 사용하고 있기 때문에 각 VM의 OS 커널과 호스트의 커널은 모두 분리돼 있다. 이 경우 VM에서 exploit을 실행하더라도 읽을 수 있는 것은 VM에서 실행되는 OS 커널의 메모리이고 따라서 이 취약점을 이용해 호스트의 메모리를 읽거나 하는 일(VM escape)은 일어날 수 없다.

하지만 VM의 OS를 패치하지 않을 경우 외부에서 공격하여 VM의 커널을 읽는 공격은 가능하고, 그렇게 되면 VM 내의 정보는 전부 유출가능하기 때문에 일단 성능저하를 감수하고라도 VM의 OS를 패치하는 것이 바람직하다. 만약 부득이 패치를 못할 상황이라면 앞서 언급한 두 가지 공격 성립 조건이 충족되지 않도록 각별하게 보안에 신경 써 주어야 한다. 외부에서 파일을 업로드하지 못하게 하거나, 파일이 업로드 되더라도 실행 권한을 막거나 하는 조치들이 필요하다.

호스트의 경우는 VM의 공격으로 인해 침해되지는 않지만 호스트가 직접 공격당하면 동일한 상황이 되므로 역시 OS패치는 권장사항이다. 하지만 장기적으로 봐서는 VM이나 호스트 양쪽 모두 패치를 하는 편이 안전하다. 지금의 해커들은 MeltDown 취약점만 사용하는 것이 아니라 공격하기 위해서 필요한 모든 방법을 복합적으로 다 동원하므로 어디 한 군데가 뚫리게 되면 남아 있는 MeltDown 취약점은 매우 크리티컬한 요소가 될 것이기 때문이다.