Skip to content
Published on

DRAM 주소 스크램블링과 보안 경계의 아래층 — 울타리가 번역보다 위에 있으면 생기는 일

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드✨Start Quiz
공유하기
Authors

이 글은 2026-08-15에 Hacker News API와 GeekNews 피드에서 직접 확인한 항목을 바탕으로 합니다. 점수와 순위는 계속 바뀝니다.

무엇이 올라와 있었나

Hacker News API로 확인한 항목입니다. 제목은 Spaghettifying DRAM, 아이템 번호는 49286341이고 2026-08-15 기준 691점에 댓글 174개입니다. 링크는 xoreaxeaxeax/skitter-creek-bath-salts GitHub 저장소입니다. GeekNews 피드에도 같은 항목이 올라와 있었습니다.

README가 설명하는 것은 DRAM 컨트롤러를 건드려 CPU의 보안 경계를 우회하는 연구 도구입니다.

문제는 검사가 아니라 층의 순서입니다

메모리 주소는 CPU에서 DRAM 칩까지 가는 동안 여러 번 번역됩니다. 가상 주소가 물리 주소가 되고, 물리 주소가 다시 채널과 뱅크와 행과 열이라는 DRAM 좌표가 됩니다. 마지막 변환을 담당하는 것이 메모리 컨트롤러입니다.

그리고 보호 장치들은 그보다 위층에 있습니다. README가 지목하는 대상은 보안 프로세서의 전용 메모리, 시스템 관리 모드가 쓰는 영역, 그리고 CPU가 절전 상태로 들어갈 때 내부 상태를 잠시 넣어 두는 구간입니다. 이 구간들은 운영체제에 보이지 않게 떼어 놓은 예약 영역이고, 접근을 막는 울타리가 물리 주소 단위로 세워져 있습니다.

여기서 구조적 결함이 드러납니다. 울타리가 물리 주소를 보고 판단하는데, 그 물리 주소가 어느 DRAM 셀로 가는지는 울타리보다 아래층에서 정해집니다. 그렇다면 아래층의 규칙을 바꿔 버리면 어떻게 될까요. 같은 셀이 다른 물리 주소로도 도달 가능해집니다. 그리고 그 다른 주소는 울타리 안쪽이 아니므로 검사를 통과합니다.

README는 이 조작을 뱅크 뒤섞기 모드와 인터리브 설정을 건드리는 것으로 설명하고, 컨트롤러 레지스터의 비트 하나를 뒤집는 형태의 예를 보여 줍니다. 요점은 정교한 공격 사슬이 아니라 설정 값 하나라는 점입니다.

별칭을 어떻게 찾아내는가

문제는 뒤섞기 규칙이 문서화되어 있지 않다는 것입니다. 설정을 바꾸면 주소가 재배치된다는 것은 알아도, 어느 주소가 어느 주소와 같은 셀을 가리키는지는 알 수 없습니다.

README가 설명하는 절차는 관측과 역산입니다. 먼저 스크램블링 모드를 여러 가지로 토글하면서 별칭 쌍을 모읍니다. 두 물리 주소가 같은 DRAM 위치를 가리킨다는 사실은 한쪽에 쓰고 다른 쪽에서 읽어 보면 확인됩니다. 이렇게 사실을 충분히 모읍니다.

그다음이 이 연구의 기술적 핵심입니다. 주소 뒤섞기는 비트들의 배타적 논리합 조합으로 표현되므로, 이것은 GF(2) 위의 선형 변환입니다. 즉 관측한 별칭 쌍들은 미지의 행렬에 대한 방정식이 되고, SMT 솔버에 넣으면 그 행렬을 복원할 수 있습니다.

행렬을 얻고 나면 방향이 뒤집힙니다. 이제 보호 영역 안의 특정 주소를 목표로 두고 그 셀에 도달하는 다른 물리 주소를 계산할 수 있습니다. README가 제목으로 쓴 스파게티라는 표현이 이것이고, 도구 이름에 들어간 되돌리기가 그 역연산입니다.

읽어 낼 수 있는 것으로 README가 드는 예는 구체적입니다. 보안 프로세서 쪽에서는 펌웨어 TPM의 RSA 엔진, 시스템 관리 모드 쪽에서는 인터럽트 처리기의 진입 벡터, 절전 예약 영역에서는 저장된 CPU 레지스터와 마이크로코드 패치입니다.

범위를 정확히 해야 합니다

여기서 과장을 걷어 내야 합니다. 댓글에서 가장 먼저 확인된 것도 이 부분이었습니다.

첫째, 이미 루트 권한이 필요합니다. 여러 댓글이 이 점을 확인했고 README의 실행 절차도 관리자 권한을 전제로 합니다. 즉 이것은 권한 상승 취약점이 아닙니다. 이미 최고 권한을 얻은 공격자가 그보다 더 아래에 있어야 할 영역까지 도달하는 이야기입니다.

둘째, 대상이 한 CPU 계열입니다. README는 AMD Family 16h만 다루며, 그 이유를 데이터시트가 DRAM 컨트롤러의 변환 레지스터를 문서화한 마지막 세대이고 그것이 잠기지 않는다는 사실을 보여 주기 때문이라고 밝힙니다. 댓글에서는 이것이 2013년 무렵의 저전력 아키텍처라는 점과, 최신 세대에서 통하는지에 대한 언급이 사실상 없다는 점이 반복해서 지적됐습니다. README도 17h 이후에 적용되는지는 알 수 없다고 스스로 적고 있습니다.

셋째, 플랫폼마다 준비 작업이 다릅니다. 미리 계산해 둔 매핑 파일이 필요하고 DIMM 구성이 다르면 매핑을 새로 만들어야 합니다.

이 셋을 합치면 실제 위협 모델은 이렇습니다. 원격 공격 경로가 아니라, 물리적으로 접근 가능하고 루트를 이미 가진 특정 구형 하드웨어에서 링 마이너스 2 아래의 비밀을 꺼내는 연구입니다. 댓글에서 게임 콘솔이 언급된 것도 그 위협 모델이 정확히 들어맞기 때문입니다. 콘솔은 공격자가 기기를 손에 들고 있고, 커널을 잡는 것이 어려운 대신 잡고 나면 그 아래가 방어의 마지막 선이기 때문입니다.

이 이야기가 우리 시스템에 남기는 것

대부분의 독자는 DRAM 컨트롤러를 만지지 않습니다. 그런데 이 연구의 형태는 하드웨어 밖에서도 반복됩니다.

일반화하면 이렇습니다. N층에서 강제한 규칙은 공격자가 N-1층에서 동작할 수 있으면 무효입니다. 그리고 이 실패는 규칙이 틀려서가 아니라 규칙이 참조하는 이름이 아래층에서 다시 해석되기 때문에 생깁니다.

같은 형태를 소프트웨어에서 찾으면 금방 나옵니다. 경로 문자열로 접근을 막아 두었는데 심볼릭 링크가 그 경로를 다른 곳으로 보내는 경우, URL 문자열로 검사했는데 라이브러리가 다르게 정규화하는 경우, 컨테이너 이름으로 정책을 걸었는데 마운트가 그 아래에서 다른 파일을 보여 주는 경우가 모두 같은 구조입니다.

그래서 실무에서 가져갈 점검 하나는 이것입니다. 여러분의 접근 통제가 판단 근거로 삼는 이름을, 그 판단 이후에 누가 다시 해석하는가. 판단과 실제 접근 사이에 번역 단계가 하나라도 끼어 있고 그 단계를 공격자가 건드릴 수 있다면 검사는 장식입니다. 이 관점은 하드웨어 백도어가 실제로 무엇인가에서 다룬 갈래와 이어집니다.

두 번째 점검은 문서화와 잠금의 관계입니다. 이 연구가 특정 세대를 고른 이유는 그 세대가 레지스터를 문서화했기 때문인데, 뒤집어 보면 문서화하지 않았을 뿐 잠기지 않은 설정은 다음 세대에도 남아 있을 수 있습니다. 문서에서 지우는 것은 방어가 아닙니다.

누구에게는 해당 없는가

관리형 클라우드에서 애플리케이션을 운영하는 팀에게 이 항목은 직접적인 조치 대상이 아닙니다. 물리 접근과 루트를 전제로 하기 때문이고, 그 전제가 성립하는 시점이면 이미 다른 문제가 훨씬 큽니다.

최신 서버 CPU만 쓰는 환경도 마찬가지입니다. 대상이 2013년 무렵의 특정 계열이고 이후 세대에 대한 검증은 README에 없습니다.

반대로 실제로 챙겨야 하는 쪽은 분명합니다. 공격자가 기기를 물리적으로 소유하는 제품, 즉 키오스크, 셋톱박스, 게임기, 현장 설치 장비, 그리고 임베디드 보드입니다. 이런 제품에서 펌웨어 TPM이나 보안 프로세서를 신뢰 기반으로 삼고 있다면 그 신뢰가 어느 층의 울타리에 의존하는지 확인할 가치가 있습니다.

정리

이 저장소가 보여 주는 것은 새로운 암호 해독이 아니라 배치의 실수입니다. 울타리를 주소 변환보다 위에 세우면, 변환을 바꿀 수 있는 사람에게 그 울타리는 없는 것과 같습니다. 그리고 범위는 정직하게 좁습니다. 루트가 필요하고, 한 CPU 계열에서 확인됐으며, 플랫폼마다 준비가 다릅니다. 남는 교훈은 특정 칩이 아니라 층의 순서입니다.

원문과 관련 글

층의 순서에 대한 일반화와 소프트웨어 쪽 사례는 저장소 문서에서 확인한 내용을 바탕으로 제가 정리한 것입니다.

Discuss on Twitter • View on GitHub