이 영역을 누르면 첫 페이지로 이동
천천히 꾸준히 조용히 블로그의 첫 페이지로 이동

천천히 꾸준히 조용히

페이지 맨 위로 올라가기

천천히 꾸준히 조용히

천천히 꾸준히 조용히.. i3months 블로그

[SSS] Hardware-based Security Techniques

  • 2025.11.27 21:09
  • Computer Science/Computer Security
반응형

 

 

 

포인터 개념을 사용하는 언어에서, 포인터가 NULL(0)을 가리킬 때 해당 주소의 함수를 호출하거나 데이터를 쓰려고 하면 NULL Pointer DeReference가 발생한다.  (0x00000000 에 있는 명령어를 실행하려 함)

 

공격자가 User Space에 있는 0x0 주소 근처에 ShellCode를 심어두면, 커널이 NULL 포인터 버그로 0x0 주소로 점프하면 커널 권한을 가진 상태로 공격자가 심어둔 사용자 영역의 코드가 실행된다.

 

이 공격을 Return-to-User 공격이라고 부른다.

 

Supervisor Mode Execution Prevention (SMEP) 와 Supervisor Mode Access Prevention (SMAP) 은 CPU 하드웨어 차원에서 커널의 User 메모리 접근을 방지하기 위해 도입됐다.

 

SMEP가 켜져 있으면 커널이 버그로 0x0으로 점프하더라도 CPU가 차단하고 Exception을 뱉음.

SMAP는 커널 모드가 사용자 영역의 데이터에 접근하는 작업 자체를 막는다. SMAP가 좀 더 강력함.

 

 

 

 

 

CPU는 현재 시스템의 중요한 제어 상태를 저장하기 위해 Control Register라는 특별한 레지스터를 가지고 있다.

SMEP와 SMAP 기능은 CR4 레지스터의 특정 비트를 켜고 끄는 것으로 작동함.

 

20번째 비트 - SMEP

21번째 비트 - SMAP

 

OS가 부팅될 때 이 비트를 1로 설정하면 하드웨어 수준에서 보호된다.

 

해커들이 공격 할 때는? 단편적으로는 저 비트를 공격할 수 있음. CR4 레지스터 값을 조작하는 명령어 수행.

 

다른 방법으로는 메모리 영역의 속성을 속일 수 있다.

가상 메모리 주소는 페이지 테이블을 거쳐 물리 주소로 변환되는데, 각 단계에서는 현재 페이지가 사용자 전용인지 관리자 전용인지를 표시하는 U/S 비트를 가지고 있음.

SMEP는 커널이 User 페이지를 실행하는 작업을 막으니, 공격 코드가 들어있는 User 페이지를 커널 페이지로 속이면? 공격 성공~

 

 

 


 

 

 

 

C/C++ 은 메모리 관리를 프로그래머가 직접 해야 하니 BOF 공격에 매우 취약하다.

 

인텔은 Skylake 프로세서부터 하드웨어 수준에서 포인터의 범위를 검사하는 Memory Protection eXtension (MPX) 기술을 도입했다.

포인터가 가리키는 메모리의 시작 주소 / 끝 주소를 미리 기록해 두고, 포인터를 사용할 때 마다 하드웨어가 범위를 체크한다.

 

이론만 들었을 때는 참 좋은 기술이지만.. 포인터 하나를 감시하기 위해 범위 정보를 저장해야 해서 메모리 사용량이 대폭 증가함.

레지스터 개수도 적어서 메모리에 값을 써야 하는데, 이 작업 자체가 오버헤드가 굉장히 크다;; 

 

대안으로 Memory Protection Keys (MPK) 가 도입됐다. MPX가 모든 요소를 전부 다 검사했다면, MPK는 구역을 나눠서 관리하는 전략을 사용한다.

 

메모리 페이지들을 16개의 도메인 중 하나에 배치한다.

PTE에 4비트를 할당해 해당 페이지가 어떤 도메인에 속하는지 표시한다. 4비트니까 0~15 까지 할당 가능.

CPU에는 pkru라는 32비트짜리 레지스터가 있는데, 이 레지스터로 각 도메인에 대한 권한을 관리한다.

 

중요한 데이터가 들어있는 도메인은 기본적으로 잠긴 상태임. 필요하면 User Program이 wrpkru를 사용해 문을 열고 접근한다.

서버의 비밀키를 별도의 도메인으로 지정하고, 평소에는 잠가 둔다. 이러면 해커가 메모리를 긁으려 해도 접근 권한이 없어 차단됨.

 

즉, 페이작 어떤 도메인에 속하는지는 OS가 정하고 도메인에 접근하는건 애플리케이션이 결정한다.

기존에도 mprotect() 같은 시스템 콜으로 메모리 권한을 바꿀 수 있긴 했음. 그런데 매우 느리다.. 그러니 MPK가 등장.

 

 

ARM 에서도 Pointer Authentication 이라는 기술을 사용함.  

 

64비트 CPU라고 해서 주소 공간 64비트를 전부 다 사용하지는 않는다. 

리눅스는 하위 48비트만 실제 주소로 사용하고, 나머지 상위 16비트는 그냥 비워둔다.

어차피 노는 공간이니까.. Pointer Authentication Code로 사용해보자는 아이디어에서 도입됨.

 

PAC를 만들고 검증하는 과정은 암호화 기술과 유사하다.

Pointer / Key / Modifier 를 섞어서 암호화하고, 결과물의 일부를 포인터의 남는 상위 비트에 적는다.

 

ARM은 이 기능을 위해 새로운 명령어 set를 추가했다. 

 

PAC - 포인터에 인증 코드를 생성함 

AUT - 포인터를 사용할 때 인증 코드가 맞는지 확인함

 

ROP는 스택에 저장된 복귀 주소를 조작하는 공격이다.

스택 저장 전 복귀 주소에 PAC를 추가하자. 해커는 비밀 키가 없으니 제대로 된 PAC를 만들 수 없다.

함수가 끝나고 돌아갈 때 서명을 확인한다. 해커가 건드린 주소는 서명이 맞지 않으니 인증에 실패하고 CPU는 에러를 뱉는다.

 

 

 


 

 

 

 

ARM의 Memory Tagging Extensions 는 PA와 다른 방식으로 메모리를 보호한다.

메모리와 포인터에 색깔을 칠해서 짝을 맞추는 방식으로 작동함. (Tag)

 

malloc으로 메모리를 빌릴 때, 무작위로 태그를 골라 메모리 공간과 포인터에 칠해준다.

이제 CPU는 메모리에 접근할 때 마다 포인터의 색깔과 실제 메모리의 색깔이 같은지 확인함. 

 

 

 

 

16바이트 크기의 메모리를 할당받아 파란색을 칠했다. 바로 옆 메모리는 노란색임.

파란색 포인터를 사용해 노란색 영역에 접근하려 하지만, 색이 일치하지 않으니 접근이 차단됨.

free 하고 다시 할당하더라도 태그는 다른 색으로 할당됨.

 

 

 

 


 

 

 

 

인텔은 Control-flow Enforcement Technology (CET) 를 사용해 해킹을 방어한다.

 

스택은 돌아갈 주소와 변수가 섞여 있어 BOF와 ROP 공격의 대상이 됐다.

즉, 돌아갈 주소를 기존 스택 말고 다른 공간에 저장하면 공격당하지 않음.

 

이런 개념에서 Shadow Stack이 도입됐다.

돌아갈 주소를 Data Stack과 Shadow Stack 두 곳에 동시에 저장하고, RET 시 두 스택에서 주소를 꺼내 서로 같은지 비교한다.

Shadow Stack은 페이지 테이블의 특수 속성으로 보호해 일반적인 명령어로는 조작할 수 없다.

 

RET 대신 JMP나 CALL 명령어를 악용하는 공격을 막을 때는 다른 방식을 사용함.

점프할 수 있는 목적지에는 표지판을 세워둔다. ENDBRANCH라는 명령어를 만들어 유효한 점프 목적지에 적어둔다.

 

 

 

 


 

 

 

인텔의 Software Guard Extensions (SGX) 는 운영체제도 신뢰하지 않는다.

 

기존 보안 모델에서는 OS를 전적으로 신뢰하기에.. OS 자체가 해킹당하거나 시스템 관리자가 마음만 먹으면 모두 털어버릴 수 있음.

그러니 OS 를 믿지 않고, CPU 하드웨어만 믿는다.

 

 

 

메모리 안에 Enclave라고 불리는 절대 안전구역을 만든다.

 

Enclave 영역에 저장되는 데이터가 메모리에 올라올 때는 항상 암호화 된 상태.

CPU 내부로 들어왔을 때만 하드웨어 수준에서 복호화되고 평문으로 보인다.

 

OS나 다른 프로그램이 저 메모리 영역을 읽으려 하면 암호화된 쓰레기 값만 볼 수 있어 안전하다.

 

비밀 작업이 필요하면 Enclave를 생성하고, 작업이 끝나면 결과만 가지고 다시 일반 영역으로 돌아온다.

 

 

 

 

 

 

Trusted Execution Environment (TEE) 기술 중 하나임. 

다만 SGX는 앱을 신뢰 영역과 비신뢰 영역으로 쪼개야 해서 개발이 좀 번거롭다.

 

DRM 도 연관되어있음. 

넷플 볼 때 Enclave에서만 영상의 암호를 풀고, OS에서는 원본 데이터를 넘겨주지 않는다.

그러니 OS가 메모리를 읽으려 하면 암호화된 쓰레기값만 보이게 되고.. OS 위에서 동작하는 캡쳐 프로그램이 검은 화면만 녹화하게 됨.

 

 

 

 


 

 

 

인텔의 Transactional Synchronization Extensions (TSX) 는 원래 성능을 높이기 위해 만든 기술인데, 해커들이 이걸 기가 막히게 악용해서 KASLR을 찾는 도구로 사용해버림.

 

데이터베이스의 트랜잭션 개념을 CPU에 도입해, 트랜잭션 도중에 다른 프로세스가 내가 쓰고 있는 데이터를 건드리면 충돌이 발생하고 _xbegin 지점으로 되돌아간다.

 

문제는 실패하면 조용히 롤백한다는 것.

일반적인 프로그램이 커널 메모리를 읽으려고 하면 Segmentation Fault를 뱉는데, 트랜잭션 안에서 커널 메모리를 읽으려 하면 프로그램이 안 죽고 트랜잭션만 취소된다.

즉, 프로그램이 죽지 않고 커널 메모리를 확인할 수 있음..

 

 

 

 

 

 

 

반응형
저작자표시 (새창열림)

'Computer Science > Computer Security' 카테고리의 다른 글

[SSS] CPU vulnerabilities and SideChannel Attack  (0) 2025.12.04
[SSS] Trusted Execution Environment 2  (0) 2025.11.24
[SSS] OPTEE - Open Portable Trusted Execution Environment  (0) 2025.11.20
[SSS] Trusted Execution Environment  (0) 2025.11.14
[SSS] Software Defense  (0) 2025.11.10

댓글

이 글 공유하기

  • 구독하기

    구독하기

  • 카카오톡

    카카오톡

  • 라인

    라인

  • 트위터

    트위터

  • Facebook

    Facebook

  • 카카오스토리

    카카오스토리

  • 밴드

    밴드

  • 네이버 블로그

    네이버 블로그

  • Pocket

    Pocket

  • Evernote

    Evernote

다른 글

  • [SSS] CPU vulnerabilities and SideChannel Attack

    [SSS] CPU vulnerabilities and SideChannel Attack

    2025.12.04
  • [SSS] Trusted Execution Environment 2

    [SSS] Trusted Execution Environment 2

    2025.11.24
  • [SSS] OPTEE - Open Portable Trusted Execution Environment

    [SSS] OPTEE - Open Portable Trusted Execution Environment

    2025.11.20
  • [SSS] Trusted Execution Environment

    [SSS] Trusted Execution Environment

    2025.11.14
다른 글 더 둘러보기

정보

천천히 꾸준히 조용히 블로그의 첫 페이지로 이동

천천히 꾸준히 조용히

  • 천천히 꾸준히 조용히의 첫 페이지로 이동

검색

방문자

  • 전체 방문자
  • 오늘
  • 어제

카테고리

  • 분류 전체보기 (679) N
    • Algorithm (205)
      • Data Structure (5)
      • Theory && Tip (33)
      • Baekjoon (166)
      • ALGOSPOT (1)
    • Spring (123)
      • Spring (28)
      • Spring Web MVC (20)
      • Spring Database (14)
      • Spring Boot (6)
      • Spring 3.1 (11)
      • Spring Batch (6)
      • Spring Security (16)
      • JPA (12)
      • Spring Data JPA (5)
      • QueryDSL (4)
      • eGovFramework (1)
    • Programming Language (74)
      • C (25)
      • C++ (12)
      • Java (19)
      • JavaScript (15)
      • Python (1)
      • PHP (2)
    • Computer Science (142)
      • Machine Learning (38)
      • Operating System (18)
      • Computer Network (28)
      • System Programming (22)
      • Universial Programming Lang.. (8)
      • Computer Architecture (4)
      • Compiler Design (11)
      • Computer Security (13)
    • Database (21)
      • Database (7)
      • MySQL (3)
      • Oracle (3)
      • Redis (5)
      • Elasticsearch (3)
    • DevOps (20)
      • Docker && Kubernetes (8)
      • Jenkins (4)
      • Amazon Web Service (8)
    • Mobile (28)
      • Android (21)
      • Flutter (7)
    • 💡 솔루션 (17)
    • 👥 모각코 (10)
    • 💬 기록 (8) N
    • 📚 공부 (6)
    • -------------- (25)

최근 글

나의 외부 링크

메뉴

  • 홈
반응형

정보

i3months의 천천히 꾸준히 조용히

천천히 꾸준히 조용히

i3months

블로그 구독하기

  • 구독하기
  • RSS 피드

티스토리

  • 티스토리 홈
  • 이 블로그 관리하기
  • 글쓰기
Powered by Tistory / Kakao. Copyright © i3months.

티스토리툴바