현대 컴퓨팅 환경에서는 보안 문제가 운영 체제(OS) 취약점과 소프트웨어 버그를 넘어 확장됩니다. 추상화의 깊은 곳에서는 최대 성능을 추출하기 위해 설계된 복잡한 마이크로아키텍처 - 파이프라인, 캐시, 버퍼 및 실행 엔진 - 가 발전해 왔습니다. 역설적으로, 이러한 특징은 새로운 미묘한 보안 위험을 야기하며, 이는 마이크로아키텍처 공격으로 알려져 있습니다. 이러한 공격은 동시 실행 애플리케이션 간에 발생하는 마이크로아키텍처 상태의 비의도적 공유 - 그리고 누출 - 를 악용하며, 때로는 완벽히 안전한 소프트웨어에서도 발생할 수 있습니다.
이 포괄적인 블로그 게시물은 마이크로아키텍처 공격을 다루며 이해를 돕기 위한 것입니다:
초보자, 연구원, 소프트웨어 개발자 또는 사이버 보안 전문가든 이 가이드는 이러한 강력한 현대 공격을 이해하고 이에 맞서 방어하는 방법을 알 수 있도록 도와줄 것입니다.
마이크로아키텍처 공격은 프로세서 하드웨어 디자인의 저수준에서 의도치 않은 정보 누출을 악용하는 기술입니다.
일반적인 소프트웨어 익스플로잇과 달리, 마이크로아키텍처 공격은 애플리케이션이나 OS의 프로그래밍 버그를 필요로 하지 않습니다. 대신, 현대 CPU가 성능을 최대화하기 위해 캐시를 공유하거나 명령어를 재정렬하는 방식 등을 악용합니다.
현대 CPU는 애플리케이션 및 심지어 가상 머신 간에 중요한 하드웨어 구조를 공유합니다. 예를 들어:
이러한 구조가 완벽히 격리되지는 않아, 한 프로세스는 종종 다른 프로세스의 영향을 관찰하거나 추론할 수 있습니다. 공격자는 이러한 암묵적 공유를 악용하여 메모리 접근 시간의 미세한 변화와 같은 간접적인 물리적 효과를 관찰하여 비밀을 추출합니다.
크게 두 가지 범주가 있습니다:
은닉 채널은 시스템 디자인에 계획되지 않은 두 행위자(송신자와 수신자) 간의 통신 경로를 생성합니다. 한 애플리케이션이 공유 자원을 조정하고, 다른 애플리케이션이 이러한 변동을 관찰하여 메시지를 재구성합니다.
예:
부채널 공격은 직접적인 통신 없이 민감한 정보를 유출합니다. 대신, 피해자의 활동으로 "흘러나오는" 정보를 악용합니다.
예:
두 채널 모두 하나의 프로세스가 다른 프로세스에 대한 정보를 추론할 수 있도록 하며, 때로는 컨테이너, VM, 사용자 경계를 넘어섭니다.
이기종 컴퓨팅 시스템은 동일한 플랫폼에 여러 프로세서 유형(범용 CPU, GPU, FPGA, AI 가속기 등)을 포함하며, 메모리 또는 마이크로아키텍처 상태를 일부 공유할 수 있습니다.
GPU와 CPU가 캐시 영역을 공유한다고 가정합니다. GPU에서 실행 중인 낮은 권한의 프로세스가 캐시를 "프라임"할 수 있고, CPU에서 실행 중인 높은 권한의 프로세스가 메모리 접근을 통해 비밀을 무의식적으로 드러낼 수 있습니다. 그러면 낮은 권한의 프로세스가 변화를 관찰하고 보호된 정보를 추론할 수 있습니다.
RISC-V는 연구 및 상업용 임베디드 시스템을 위한 빠르게 인기를 얻고 있는 오픈 소스 모듈식 명령어 세트 아키텍처입니다. 마이크로아키텍처 공격이 x86과 ARM에서 잘 연구된 반면, 최근의 연구는 RISC-V도 동일하게 취약하다는 것을 보여줍니다.
핵심 요점: 어떤 명령어 세트나 오픈 소스 하드웨어도 면역이 아닙니다—공유 마이크로아키텍처가 있는 모든 CPU는 특별히 강화되지 않는 한 취약합니다.
새로운 분야: 스택 엔진 공격 (출처)
공격자와 피해자가 CPU를 공유하는 경우, 공격자는 맞춤화된 스택 작업을 수행하고 결과적인 타이밍을 관찰함으로써 피해자가 최근에 수행한 스택 활동을 추론할 수 있습니다.
Spectre 및 Meltdown (2018)은 마이크로아키텍처 공격이 이론 이상의 것이며, 수십억 대의 컴퓨터에 영향을 미침을 깨닫게 했습니다.
[피해자 프로세스] [공격자 프로세스]
비밀 데이터로 명령어 실행 캐시를 채우고 접근 시간 측정
---[물리적으로 캐시를 공유]---
Prime+Probe는 다음과 같이 동작하는 고전적인 공격입니다:
극장 모든 좌석에 동전을 놓고(프라임), 누군가가 들어와서 앉고(피해자), 빈 좌석을 확인함(probe)—직접적으로 관찰하지 않고도 피해자가 앉은 좌석을 밝혀냅니다.
최근 공격은 스택 엔진 최적화를 목표로 합니다:
강조해야 할 사항: 생산 시스템에서의 실습 공격은 동의 없이 불법입니다. 그러나 연구 및 방어를 위해 타이밍 부채널을 드러내는 성능 측정은 컴퓨터 테스트 환경에서 수행할 수 있습니다.
캐시 공유를 검사하기 위한 간단한 타이밍 프로브 (예: 가상 머신에서).
#!/bin/bash
buffer=/tmp/testmem
size=1024000
# 큰 버퍼 할당
dd if=/dev/urandom of="$buffer" bs=1K count=1000
# 반복적으로 메모리에 접근하여 캐시 "프라임"
function prime_cache {
for i in $(seq 1 $size); do
tail -c +$i "$buffer" | head -c 1 >/dev/null
done
}
# 접근 시간 측정
function time_access {
/usr/bin/time -f "%e" dd if="$buffer" of=/dev/null bs=1K count=1000 2>&1
}
echo "캐시 프라임 중..."
prime_cache
echo "읽기 접근 시간 측정 중..."
time_access
# 이제 다른 프로세스에 메모리 집중 작업을 실행하게 하고 반복
# 시간 변경 확인, 캐시 충돌을 나타낼 수 있음!
타이밍이 크게 바뀌면, 이는 다른 프로세스와의 캐시 충돌 증거로 해석할 수 있으며, 잠재적으로 Prime+Probe 공격을 가능하게 할 수 있습니다.
time 모듈 및 numpy 배열을 사용하는 더 정밀한 방법으로 반복되는 메모리 접근 패턴을 측정합니다.
import numpy as np
import time
# 큰 배열 할당
arr = np.zeros((1024 * 1024 * 10,), dtype=np.uint8)
def probe_access():
ts = time.time()
# 모든 요소에 접근하여 캐시 적재 강제
for i in range(0, len(arr), 64):
arr[i] += 1
te = time.time()
print(f"접근 시간: {te - ts:.6f} 초")
# 첫 실행: 차가울 가능성 있음(페이지 폴트 발생 가능)
probe_access()
# 두 번째 실행: 캐시가 뜨거울 가능성 있음
probe_access()
이제 두 번째 터미널(또는 별도의 프로세스)에서 메모리 집중 스크립트(예: stress-ng 등)를 실행하여 캐시 라인을 비워냅니다. probe_access()를 다시 실행하고 시간 증가를 관찰합니다.
다른 프로세스가 실행된 후 접근 시간이 증가하는 것을 발견하면, 이는 시스템의 캐시가 타이밍 공격에 취약하다는 의미일 수 있습니다.
마이크로아키텍처 공격의 지속적인 존재에 따라 보안 수호자들은 무엇을 할 수 있을까요?
# 플러시 관련 CPU 기능 확인
grep . /proc/cpuinfo | grep -E 'flush|clflush|clwb'
# clflush 등 표시 가능, 소프트웨어에 의해 캐시를 지울 수 있는 지침을 나타냅니다.
많은 CPU 벤더들이 다음과 같은 기능을 도입하고 있습니다:
하지만 대부분의 배포된 CPU는 여전히 취약하며, 특히 클라우드 환경이나 복잡한 하드웨어에서 그럴 수 있습니다.
마이크로아키텍처 공격은 더 이상 "이론적 호기심"에 불과하지 않습니다. 프로세서가 더 최적화되고 공유될수록 내부 설계의 미세한 부분이 숙련된 공격자의 강력한 도구가 됩니다.
특히 이기종 시스템에서, CPU, GPU 및 가속기가 마이크로아키텍처 상태를 공유하는 환경에서는 은닉 및 부채널이 가능할 뿐만 아니라 흔합니다. 최근 RISC-V CPU와 스택 엔진에 대한 공격은 이러한 위험이 모든 아키텍처와 최적화에 대해 보편적이고 지속적으로 관련성이 있다는 것을 보여줍니다.
항상 최신 정보를 유지하고, 자신의 환경을 테스트하며, 소프트웨어와 하드웨어에서 더 나은 격리를 요구하십시오.
이 글은 교육 목적으로 작성되었습니다. 항상 안전하고 통제된 환경에서 테스트하십시오.
이 콘텐츠가 유용하다고 생각하셨다면, 저희의 포괄적인 47주 엘리트 교육 프로그램으로 무엇을 달성할 수 있을지 상상해 보세요. Unit 8200 기술로 경력을 변화시킨 1,200명 이상의 학생들과 함께하세요.