맨위로가기

실행 가능 공간 보호

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

실행 가능 공간 보호는 메모리 영역에서 코드 실행을 제한하여 보안을 강화하는 기술이다. 다양한 운영 체제에서 구현되며, 하드웨어의 NX 비트(No-eXecute bit) 또는 소프트웨어 에뮬레이션을 활용한다. 안드로이드, FreeBSD, 리눅스, macOS, NetBSD, OpenBSD, 솔라리스, 윈도우 등에서 구현되었으며, Xbox에서도 유사한 보호 기법이 사용되었다. 하지만 JIT 컴파일이나 ROP(Return-oriented programming) 기법을 사용하는 공격에는 한계가 있다.

더 읽어볼만한 페이지

  • 운영 체제 보안 - NX 비트
    NX 비트는 하드웨어 기반 보안 기능으로, 메모리 페이지의 실행 권한을 제어하여 특정 영역에서 코드 실행을 막아 버퍼 오버플로 공격과 같은 보안 위협을 줄이는 데 사용되며, AMD에서 처음 도입 후 다양한 프로세서와 운영체제에서 DEP 등의 이름으로 구현되었다.
  • 운영 체제 보안 - 슈퍼유저
    슈퍼유저는 운영 체제에서 모든 권한을 가진 사용자를 지칭하며, 유닉스 계열에서는 root, 윈도우에서는 관리자 계정이 해당 역할을 수행한다.
실행 가능 공간 보호
보안
유형완화 기술
설명메모리 내의 특정 영역을 실행 불가능으로 표시하여 악성 코드가 해당 영역에서 실행되는 것을 방지하는 보안 기능
구현
하드웨어NX 비트 (AMD)
XD 비트 (Intel)
운영 체제Windows (데이터 실행 방지)
Linux (Exec Shield, PaX)
macOS (데이터 실행 방지)
Android
OpenBSD (W^X)

2. 구현

다음은 다양한 운영 체제에서의 실행 가능 공간 보호 구현에 대한 내용이다.

== 구현 ==

많은 운영 체제들이 실행 가능 공간 보호를 구현하거나 정책을 가지고 있다. 다음은 알파벳 순서로 이러한 시스템을 목록화한 것이다.

아키텍처 독립적인 에뮬레이션을 제공하는 기술은 하드웨어 지원이 없는 프로세서에서도 사용 가능하다.

많은 운영 체제는 실행 가능 공간 보호 정책을 구현하거나 사용할 수 있다.

종종 NX 비트와 같은 하드웨어 기능을 이용한다. NX 비트는 AMD의 AMD64 시리즈 CPU에 탑재된다. 인텔 CPU (펜티엄 4의 프레스콧 코어 이후)의 XD 비트(eXecute Disable, EDB: Execute Disable Bit)도 동등한 기능이다. 썬의 SPARC, 알파, IBM의 파워PC 그리고 인텔의 IA-64(아이테니엄/머세드)의 일부에도 동등한 기능이 있다.

리눅스에서의 구현은 PaX나 Exec Shield, OpenBSD에서는 W^X나 Openwall 등이 있다.

Windows에서의 구현은 데이터 실행 방지(DEP)가 있다. DEP에는 하드웨어 DEP와 소프트웨어 DEP가 있으며, 하드웨어 DEP에서는 NX 비트 기능을 통해 데이터버퍼 내에 있는 코드의 실행을 금지한다. 소프트웨어 DEP에서는 이름은 유사하지만 그러한 기능(버퍼 오버런으로부터의 보호)은 없고, 대신 특정 공격(구조화된 예외 처리기 덮어쓰기)으로부터 보호한다.

기존의 응용 소프트웨어나 운영 체제와의 호환성, 보호 범위(응용 프로그램 전반까지, 운영 체제의 일부 기능만 등), 다양한 공격에 대한 취약성은 각 구현에 따라 다르다.

=== 안드로이드 ===

안드로이드 2.3 이후부터, 기본으로 실행 불가 스택과 힙을 포함하는 실행 불가 페이지들을 지원한다.[16][17][18] 이를 지원하는 아키텍처는 기본적으로 실행 불가능한 페이지, 즉 실행 불가능한 스택 및 힙을 갖추고 있다.[1][2][3]

종종 NX 비트와 같은 하드웨어 기능을 이용한다. NX 비트는 AMD의 AMD64 시리즈 CPU에 탑재된다. 인텔 CPU (펜티엄 4의 프레스콧 코어 이후)의 XD 비트(eXecute Disable, EDB: Execute Disable Bit)도 동등한 기능이다. 썬의 SPARC, 알파, IBM의 파워PC 그리고 인텔의 IA-64(아이테니엄/머세드)의 일부에도 동등한 기능이 있다.

=== FreeBSD ===

NX 비트에 대한 초기 지원은 이를 지원하는 x86-64 및 IA-32 프로세서에서 2004년 6월 8일에 FreeBSD -CURRENT에 처음 나타났으며, 5.3 릴리스 이후의 FreeBSD 릴리스에 포함되었다. NX 비트는 AMD의 AMD64 시리즈 CPU에 탑재되며, 인텔 CPU (펜티엄 4의 프레스콧 코어 이후)의 XD 비트(eXecute Disable, EDB: Execute Disable Bit)도 동등한 기능을 제공한다. 썬의 SPARC, 알파, IBM의 파워PC, 그리고 인텔의 IA-64(아이테니엄/머세드)의 일부에도 비슷한 기능이 있다.

=== 리눅스 ===

리눅스 커널은 x86-64와 IA-32 프로세서에서 NX 비트를 지원한다. 이러한 특징들은 커널 버전 2.6.8 이후부터 리눅스 커널에 포함되었다.[19]

2비트 x86 커널은 일반적으로 NX 비트를 예상하지 않았기 때문에, 32비트 x86 커널에서의 NX 비트 사용은 주목할만 하다. NX 활성화 패치는 이러한 커널에서의 NX 비트의 사용을 보증한다.

페도라, 우분투 그리고 오픈수세 같은 몇몇 데스크탑 리눅스 배포판들은 기본 커널에서 기본 옵션으로 (32비트 모드에서 NX 비트에의 접근 획득을 요구하는) HIGHMEM64를 활성화시키지 않았는데, 이것은 PAE 모드가 펜티엄 프로 이전과 셀러론 그리고 펜티엄 M에서(NX 지원이 없는) 부팅 실패를 유발할 수 있기 때문이다. 페도라 코어 6와 우분투 9.10 이후에서는 PAE와 NX를 지원하는 커널-PAE 패키지를 제공한다.

NX 메모리 보호는 지원하는 하드웨어를 갖는 모든 우분투에서 사용 가능 했었다. 우분투 9.10 이후의 32비트 PAE 데스크톱 커널 또한 NX CPU 특징을 갖는 하드웨어를 필요로 한다. NX 하드웨어가 존재하지 않는 시스템들에서 32비트 커널은 소프트웨어 에뮬레이션을 통해 NX CPU 특징을 어느 정도 제공한다.

실행 불가 기능 또한 x86이 아닌 다른 프로세서들에 존재한다.

리눅스 커널은 AMD, 인텔, 트랜스메타(Transmeta), VIA 등 최신 64비트 프로세서와 같이 NX 비트를 지원하는 x86-64 및 IA-32 프로세서를 지원한다. x86-64 CPU의 64비트 모드에서 이 기능을 지원하는 것은 2004년 안디 클린에 의해 추가되었으며, 같은 해 잉고 몰나르는 64비트 CPU에서 32비트 모드에 대한 지원을 추가했다. 이러한 기능은 2004년 8월 커널 버전 2.6.8 릴리스 이후 리눅스 커널 메인라인의 일부였다.[4]

32비트 x86 CPU와 64비트 IA-32 호환 CPU에서 모두 실행될 수 있는 32비트 x86 커널에서 NX 비트의 가용성은 중요하다. 32비트 x86 커널은 일반적으로 AMD64 또는 IA-64가 제공하는 NX 비트를 예상하지 않기 때문이다. NX 활성화 패치는 이러한 커널이 NX 비트가 존재할 경우 사용을 시도하도록 보장한다.

페도라, 우분투, openSUSE와 같은 일부 데스크톱 리눅스 배포판은 기본 커널에서 HIGHMEM64 옵션을 기본적으로 활성화하지 않는다. 이는 32비트 모드에서 NX 비트에 접근하는 데 필요하다. 왜냐하면 NX 비트를 사용하기 위해 필요한 PAE 모드는 NX를 지원하지 않는 펜티엄 프로 이전(펜티엄 MMX 포함) 및 셀러론 M, 펜티엄 M 프로세서에서 부팅 실패를 유발하기 때문이다. PAE를 지원하지 않는 다른 프로세서로는 AMD K6 및 이전, 트랜스메타 크루소, VIA C3 및 이전, 지오드 GX 및 LX가 있다. VMware Workstation 4.0 이전 버전, Parallels Workstation 4.0 이전 버전, 마이크로소프트 버추얼 PC 및 버추얼 서버는 게스트에서 PAE를 지원하지 않는다. 페도라 코어 6 및 우분투 9.10 이상은 PAE 및 NX를 지원하는 커널-PAE 패키지를 제공한다.

NX 메모리 보호는 하드웨어를 지원하고 64비트 커널 또는 32비트 서버 커널을 실행하는 모든 시스템에 대해 우분투에서 항상 사용 가능했다. 우분투 9.10 이상에 있는 32비트 PAE 데스크톱 커널(linux-image-generic-pae)은 또한 NX CPU 기능을 갖춘 하드웨어에 필요한 PAE 모드를 제공한다. NX 하드웨어가 없는 시스템의 경우, 32비트 커널은 이제 공격자가 스택 또는 힙 메모리에서 실행할 수 있는 많은 익스플로잇을 차단하는 데 도움이 될 수 있는 소프트웨어 에뮬레이션을 통해 NX CPU 기능의 근사치를 제공한다.

실행 불가 기능은 또한 이 기능을 지원하는 다른 x86 외 프로세서에도 많은 릴리스에서 존재해왔다.

종종 NX 비트와 같은 하드웨어 기능을 이용한다. NX 비트는 AMD의 AMD64 시리즈 CPU에 탑재된다. 인텔 CPU (펜티엄 4의 프레스콧 코어 이후)의 XD 비트(eXecute Disable, EDB: Execute Disable Bit)도 동등한 기능이다. 썬의 SPARC, 알파, IBM의 파워PC 그리고 인텔의 IA-64(아이테니엄/머세드)의 일부에도 동등한 기능이 있다.

리눅스에서의 구현은 PaX나 Exec Shield, OpenBSD에서는 W^X나 Openwall 등이 있다.

Windows에서의 구현은 데이터 실행 방지(DEP)가 있다. DEP에는 하드웨어 DEP와 소프트웨어 DEP가 있으며, 하드웨어 DEP에서는 NX 비트 기능을 통해 데이터버퍼 내에 있는 코드의 실행을 금지한다. 소프트웨어 DEP에서는 이름은 유사하지만 그러한 기능(버퍼 오버런으로부터의 보호)은 없고, 대신 특정 공격(구조화된 예외 처리기 덮어쓰기)으로부터 보호한다.

기존의 응용 소프트웨어나 운영 체제와의 호환성, 보호 범위(응용 프로그램 전반까지, 운영 체제의 일부 기능만 등), 다양한 공격에 대한 취약성은 각 구현에 따라 다르다.

==== Exec Shield ====

레드햇 커널 개발자 잉고 몰나르(Ingo Molnár)는 32비트 x86 CPU에서 NX 기능을 근사하고 활용하기 위해 Exec Shield라는 이름의 리눅스 커널 패치를 공개했다. Exec Shield 패치는 2003년 5월 2일 리눅스 커널 메일링 리스트에 공개되었지만, 에뮬레이션의 복잡한 부분을 처리하기 위해 핵심 코드에 몇 가지 침투적인 변경 사항이 포함되어 있어 기본 커널에 병합되는 것이 거부되었다. Exec Shield의 레거시 CPU 지원은 상위 코드 세그먼트 제한을 추적하여 NX 에뮬레이션을 근사한다. 이는 컨텍스트 전환 중에 몇 사이클의 오버헤드만 부과하며, 이는 모든 의도와 목적에 따라 측정할 수 없다. NX 비트가 없는 레거시 CPU의 경우, Exec Shield는 코드 세그먼트 제한 아래의 페이지를 보호하지 못한다. 스택과 같은 상위 메모리를 실행 가능으로 표시하는 mprotect() 호출은 해당 제한 아래의 모든 메모리를 실행 가능으로 표시한다. 따라서 이러한 상황에서 Exec Shield의 방식은 실패한다. 이것이 Exec Shield의 낮은 오버헤드의 대가이다. Exec Shield는 ELF 헤더 마킹 두 가지를 확인하여 스택 또는 힙이 실행 가능해야 하는지 여부를 결정한다. 이를 각각 PT_GNU_STACK 및 PT_GNU_HEAP라고 한다. Exec Shield를 사용하면 바이너리 실행 파일과 라이브러리 모두에 대해 이러한 제어를 설정할 수 있다. 실행 파일이 주어진 제한 완화가 필요한 라이브러리를 로드하는 경우, 실행 파일은 해당 마킹을 상속받고 해당 제한이 완화된다.


  • 하드웨어 지원 프로세서: 리눅스가 NX를 지원하는 모든 프로세서
  • 에뮬레이션: IA-32(x86) 및 호환 가능한 CPU에서 코드 세그먼트 제한을 사용한 NX 근사
  • 기타 지원: 없음
  • 표준 배포판: 페도라 코어(Fedora Core) 및 레드햇 엔터프라이즈 리눅스(Red Hat Enterprise Linux)
  • 출시일: 2003년 5월 2일


==== PaX ====

PaX NX 기술은 NX 기능이나 하드웨어 NX 비트의 사용을 에뮬레이트 할 수 있다. PaX는 32비트 x86 같은 NX 비트를 갖지 않는 x86 CPU에서 동작한다. 리눅스 커널은 PaX를 포함하지 않아서 직접 패치할 수 밖에 없다.

PaX는 두 방식의NX 비트 에뮬레이션을 제공하는데, SEGMEXEC와 PAGEEXEC이 그것이다. SEGMEXEC 방식은 작은 오버헤드가 부과되며 일반적으로 1%미만이다. 이것은 실행과 데이터 접근 사이의 분리에 사용되는 가상 메모리 미러링 때문에 발생한다.[20] SEGMEXEC 또한 작업이 보통 보다 적은 메모리 접근을 허용하게 하는, 작업의 가상 주소 공간을 이등분하는 효과를 갖는다. 이것은 작업이 보통 주소 공간의 반 이상을 요구하기 전까지는 문제가 되지 않으며, 이런 일은 거의 일어나지 않는다. SEGMEXEC는 프로그램들이 더 많은 시스템 메모리(즉 RAM)를 사용하게 하지 않아서, 단지 그들이 얼마나 접근할 수 있는지만을 제한한다. 32비트 CPU에서, 이것은 1.5 GB가 된다.

PaX는 PAGEEXEC에서 속도를 높이기 위해 Exec Shield와 비슷한 방식을 제공한다. 그러나 높은 메모리가 실행 가능하게 마크되었을 때 이 방식은 보호를 잃는다. 이러한 경우에 PaX는 CS 제한 아래 페이지를 보호하기 위한 PAGEEXEC(특정한 메모리 접근 패턴에서 더 높은 오버헤드 동작이 될 수 있는)에 의해 사용되는 오래된 이전 방식의 변수-오버헤드 방식을 사용한다. PAGEEXEC 방식이 하드웨어 NX 비트를 제공하는 CPU에서 사용될 때, 하드웨어 NX 비트가 사용되어서 주목할 만한 오버헤드가 일어나지는 않는다.

PaX는 프로그램이 메모리를 마킹하는 것(잠재적인 익스플로잇에 유용한 방식으로)을 막는 mprotect() 제한을 제공한다. 이 정책은 특정한 애플리케이션의 기능을 막기도 하지만 감염된 프로그램을 비활성화할 수도 있다.

PaX는 아래에 나오는 각 실행 가능 바이너리를 위한 기술들의 기능들에 대한 각각의 제어를 허용한다.

  • PAGEEXEC
  • SEGMEXEC
  • mprotect() 제한
  • Trampoline 에뮬레이션
  • 난수화 실행 가능 베이스
  • 난수화 mmap() 베이스

PaX는 PT_GNU_STACK와 PT_GNU_HEAP를 무시한다. 과거에 PaX는 이러한 셋팅들을 고려하는 설정이 있었지만, 보안 상의 이유로 옵션이 제거되었다. PT_GNU_STACK의 같은 결과들도 일반적으로 mprotect() 제한을 비활성화함으로써 이루어질 수 있다(프로그램이 로드된 스택을 mprotect()할 것이다). 이것은 항상 참인 것은 아니다; 이것이 실패하는 경우 간단하게 PAGEEXEC와 SEGMEXEC를 비활성화하는 것은 효과적으로 모든 실행 가능 공간 제한들을 제거할 것이다.

=== macOS ===

macOS는 인텔 기반에서 애플이 지원하는 모든 CPU (Mac OS X 10.4.4부터 – 최초의 인텔 출시 버전 – 이후)에서 NX 비트를 지원한다. Mac OS X 10.4는 NX 스택 보호만 지원했다. Mac OS X 10.5에서는 모든 64비트 실행 파일이 NX 스택 및 힙, W^X 보호 기능을 갖추고 있다. 여기에는 x86-64 (Core 2 이상) 및 G5 맥의 64비트 PowerPC가 포함된다.

=== NetBSD ===

NetBSD 2.0 버전 (2004년 12월 9일) 이상부터 이를 지원하는 아키텍처는 실행 불가능한 스택과 힙을 갖는다.[6]

페이지 단위로 세분화된 아키텍처는 다음과 같다: 알파, amd64, hppa, i386 (PAE 포함), powerpc (ibm4xx), sh5, sparc (sun4m, sun4d), sparc64. 영역 단위로만 지원하는 아키텍처는 다음과 같다: i386 (PAE 미포함), 기타 powerpc (macppc 등). 기타 아키텍처는 실행 불가능한 스택 또는 힙의 이점을 누릴 수 없다. NetBSD는 기본적으로 이러한 아키텍처에서 이러한 기능을 제공하기 위해 소프트웨어 에뮬레이션을 사용하지 않는다.

종종 NX 비트와 같은 하드웨어 기능을 이용한다. NX 비트는 AMD의 AMD64 시리즈 CPU에 탑재된다. 인텔 CPU (펜티엄 4의 프레스콧 코어 이후)의 XD 비트(eXecute Disable, EDB: Execute Disable Bit)도 동등한 기능이다. 썬의 SPARC, 알파, IBM의 파워PC 그리고 인텔의 IA-64(아이테니엄/머세드)의 일부에도 동등한 기능이 있다.

=== OpenBSD ===

OpenBSD 운영 체제의 기술인 W^X는 이를 지원하는 프로세서에서 기본적으로 쓰기 가능한 페이지를 실행 불가능으로 표시한다. 32비트 x86 프로세서에서 코드 세그먼트는 주소 공간의 일부만 포함하도록 설정되어 실행 가능 공간 보호 수준을 제공한다.

2003년 5월 1일에 출시된 OpenBSD 3.3은 W^X를 처음으로 포함했다. W^X는 종종 NX 비트와 같은 하드웨어 기능을 이용한다. NX 비트는 AMD의 AMD64 시리즈 CPU에 탑재된다. 인텔 CPU (펜티엄 4의 프레스콧 코어 이후)의 XD 비트(eXecute Disable, EDB: Execute Disable Bit)도 동등한 기능이다. 썬의 SPARC, 알파, IBM의 파워PC 그리고 인텔의 IA-64(아이테니엄/머세드)의 일부에도 동등한 기능이 있다.

=== 솔라리스 ===

솔라리스는 솔라리스 2.6(1997년)부터 SPARC 프로세서에서 스택 실행을 전역적으로 비활성화하는 것을 지원해 왔으며, 솔라리스 9(2002년)에서는 실행 파일별로 스택 실행을 비활성화하는 기능이 추가되었다. 종종 NX 비트와 같은 하드웨어 기능을 이용한다. NX 비트는 AMD의 AMD64 시리즈 CPU에 탑재된다. 인텔 CPU (펜티엄 4의 프레스콧 코어 이후)의 XD 비트(eXecute Disable, EDB: Execute Disable Bit)도 동등한 기능이다. 썬의 SPARC, 알파, IBM의 파워PC 그리고 인텔의 IA-64(아이테니엄/머세드)의 일부에도 동등한 기능이 있다.

=== 윈도우 ===

윈도우 XP 서비스 팩 2 (2004)와 윈도우 서버 2003 서비스 팩 1 (2005)를 시작으로, NX 특징들이 x86 아키텍처에서 처음으로 구현되었다.[7][8] 윈도우에서의 실행 가능 공간 보호는 "데이터 실행 방지(DEP)"라고 불린다.

윈도우 XP 또는 서버 2003 하에서 NX 보호는 중요한 윈도우 서비스에서 배타적으로 기본 옵션으로 사용되었다. 만약 x86 프로세서가 이 특징을 지원한다면 NX 특징은 기본적으로 자동으로 설정된다.

주소 공간 배치 난수화(ASLR) 없이 제공된 초기의 DEP는 잠재적인 return-to-libc 공격을 허용하였고 공격 동안 쉽게 DEP를 비활성화 할 수 있었다.[9] PaX 문서는 왜 ASLR이 필요한지를 상술하였다.[10] ASLR가 없는 환경에서 DEP에 가능한 개념 증명이 만들어졌다.[11] 이것은 오염된 이미지 같은 준비된 데이터의 주소가 공격자에게 알려질 수 있다는 것이다.

마이크로소프트는 윈도우 비스타와 윈도우 서버 2008에 ASLR 기능을 추가하였다. 이 플랫폼에서는 DEP는 PAE 커널의 자동화된 사용을 통해 구현되었다. 윈도우 비스타 DEP는 메모리의 특정한 영역을 오직 데이터만 갖게 의도함으로써 동작한다. 이로써 NX 또는 XD 비트가 프로세서를 활성화하고 실행 불가하다고 알려진다.[12] 비스타 이후의 윈도우에서 DEP가 활성화되었든지 말든지 간에 특정한 프로세스는 윈도우 작업 관리자의 프로세스 탭에서 볼 수 있다.

윈도우는 마이크로소프트의 "Safe Structured Exception Handling"(SafeSEH)을 통해 소프트웨어 DEP(NX 비트의 사용 없이)를 구현하였다. 적절하게 컴파일된 애플리케이션에서 프로그램 실행 중에 예외가 일어나면 SafeSEH는 예외 처리기가 원본에서 컴파일 된 것인지를 검사한다. 이 보호의 효과는 공격자가 자신의 예외 핸들러(데이터 페이지에 저장하거나 검사되지 않은 프로그램 입력을 통한)를 추가하지 못하게 하는 것이다.[12][13]

NX가 지원되면, 기본값으로 활성화 된다. 윈도우는 프로그램이 API나 PE 파일의 섹션 헤더를 통해 어떤 페이지를 실행 불가하게 하는 것을 허용한다. API에서 NX 비트에 대한 런타임 접근은 Win32 API 호출인 '''VirtualAlloc[Ex]'''와 '''VirtualProtect[Ex]'''를 통해 가능하다. 각페이지는 각각 실행 가능이거나 불가로 플래그될 수 있다. 이전의 x86 하드웨어 지원의 부족에도 불구하고, 실행 가능 그리고 불가 페이지 셋팅들 모두 시작 시에 제공된다. NX 이전의 CPU는 'executable' 속성이 영향을 미치지 않는다. 이것은 대부분의 프로그래머들이 적절하게 사용할 수 있게 문서화되어 있다. PE 파일 포맷에서, 각 섹션은 자신의 실행 가능함을 명시할 수 있다. 실행 플래그가 존재해서 시작 시에 표준 링커가 NX 비트 전에 이것을 사용한다. 이것 때문에 윈도우는 NX 비트를 오래된 프로그램에 강제할 수 있다.

=== Xbox ===

마이크로소프트의 Xbox에서 CPU는 NX 비트를 가지고 있지 않지만, 최신 버전의 XDK는 코드 세그먼트 제한을 커널의 '''.data''' 섹션 시작점으로 설정한다. (정상적인 상황에서는 이 지점 뒤에 코드가 없어야 한다). 버전 51xx부터 이 변경 사항은 새로운 Xbox의 커널에도 구현되었다. 이는 이전 익스플로잇이 상주 프로그램이 되기 위해 사용했던 기술을 무력화시켰다. 그러나 Xbox 커널의 근본적인 취약점은 영향을 받지 않았기 때문에 이 새로운 커널 버전을 지원하는 새로운 익스플로잇이 빠르게 공개되었다.

2. 1. 안드로이드

안드로이드 2.3 이후부터, 기본으로 실행 불가 스택과 힙을 포함하는 실행 불가 페이지들을 지원한다.[16][17][18] 이를 지원하는 아키텍처는 기본적으로 실행 불가능한 페이지, 즉 실행 불가능한 스택 및 힙을 갖추고 있다.[1][2][3]

종종 NX 비트와 같은 하드웨어 기능을 이용한다. NX 비트는 AMD의 AMD64 시리즈 CPU에 탑재된다. 인텔 CPU (펜티엄 4의 프레스콧 코어 이후)의 XD 비트(eXecute Disable, EDB: Execute Disable Bit)도 동등한 기능이다. 썬의 SPARC, 알파, IBM의 파워PC 그리고 인텔의 IA-64(아이테니엄/머세드)의 일부에도 동등한 기능이 있다.

2. 2. FreeBSD

NX 비트에 대한 초기 지원은 이를 지원하는 x86-64 및 IA-32 프로세서에서 2004년 6월 8일에 FreeBSD -CURRENT에 처음 나타났으며, 5.3 릴리스 이후의 FreeBSD 릴리스에 포함되었다. NX 비트는 AMD의 AMD64 시리즈 CPU에 탑재되며, 인텔 CPU (펜티엄 4의 프레스콧 코어 이후)의 XD 비트(eXecute Disable, EDB: Execute Disable Bit)도 동등한 기능을 제공한다. 썬의 SPARC, 알파, IBM의 파워PC, 그리고 인텔의 IA-64(아이테니엄/머세드)의 일부에도 비슷한 기능이 있다.

2. 3. 리눅스

리눅스 커널은 x86-64와 IA-32 프로세서에서 NX 비트를 지원한다. 이러한 특징들은 커널 버전 2.6.8 이후부터 리눅스 커널에 포함되었다.[19]

2비트 x86 커널은 일반적으로 NX 비트를 예상하지 않았기 때문에, 32비트 x86 커널에서의 NX 비트 사용은 주목할만 하다. NX 활성화 패치는 이러한 커널에서의 NX 비트의 사용을 보증한다.

페도라, 우분투 그리고 오픈수세 같은 몇몇 데스크탑 리눅스 배포판들은 기본 커널에서 기본 옵션으로 (32비트 모드에서 NX 비트에의 접근 획득을 요구하는) HIGHMEM64를 활성화시키지 않았는데, 이것은 PAE 모드가 펜티엄 프로 이전과 셀러론 그리고 펜티엄 M에서(NX 지원이 없는) 부팅 실패를 유발할 수 있기 때문이다. 페도라 코어 6와 우분투 9.10 이후에서는 PAE와 NX를 지원하는 커널-PAE 패키지를 제공한다.

NX 메모리 보호는 지원하는 하드웨어를 갖는 모든 우분투에서 사용 가능 했었다. 우분투 9.10 이후의 32비트 PAE 데스크톱 커널 또한 NX CPU 특징을 갖는 하드웨어를 필요로 한다. NX 하드웨어가 존재하지 않는 시스템들에서 32비트 커널은 소프트웨어 에뮬레이션을 통해 NX CPU 특징을 어느 정도 제공한다.

실행 불가 기능 또한 x86이 아닌 다른 프로세서들에 존재한다.

리눅스 커널은 AMD, 인텔, 트랜스메타(Transmeta), VIA 등 최신 64비트 프로세서와 같이 NX 비트를 지원하는 x86-64 및 IA-32 프로세서를 지원한다. x86-64 CPU의 64비트 모드에서 이 기능을 지원하는 것은 2004년 안디 클린에 의해 추가되었으며, 같은 해 잉고 몰나르는 64비트 CPU에서 32비트 모드에 대한 지원을 추가했다. 이러한 기능은 2004년 8월 커널 버전 2.6.8 릴리스 이후 리눅스 커널 메인라인의 일부였다.[4]

32비트 x86 CPU와 64비트 IA-32 호환 CPU에서 모두 실행될 수 있는 32비트 x86 커널에서 NX 비트의 가용성은 중요하다. 32비트 x86 커널은 일반적으로 AMD64 또는 IA-64가 제공하는 NX 비트를 예상하지 않기 때문이다. NX 활성화 패치는 이러한 커널이 NX 비트가 존재할 경우 사용을 시도하도록 보장한다.

페도라, 우분투, openSUSE와 같은 일부 데스크톱 리눅스 배포판은 기본 커널에서 HIGHMEM64 옵션을 기본적으로 활성화하지 않는다. 이는 32비트 모드에서 NX 비트에 접근하는 데 필요하다. 왜냐하면 NX 비트를 사용하기 위해 필요한 PAE 모드는 NX를 지원하지 않는 펜티엄 프로 이전(펜티엄 MMX 포함) 및 셀러론 M, 펜티엄 M 프로세서에서 부팅 실패를 유발하기 때문이다. PAE를 지원하지 않는 다른 프로세서로는 AMD K6 및 이전, 트랜스메타 크루소, VIA C3 및 이전, 지오드 GX 및 LX가 있다. VMware Workstation 4.0 이전 버전, Parallels Workstation 4.0 이전 버전, 마이크로소프트 버추얼 PC 및 버추얼 서버는 게스트에서 PAE를 지원하지 않는다. 페도라 코어 6 및 우분투 9.10 이상은 PAE 및 NX를 지원하는 커널-PAE 패키지를 제공한다.

NX 메모리 보호는 하드웨어를 지원하고 64비트 커널 또는 32비트 서버 커널을 실행하는 모든 시스템에 대해 우분투에서 항상 사용 가능했다. 우분투 9.10 이상에 있는 32비트 PAE 데스크톱 커널(linux-image-generic-pae)은 또한 NX CPU 기능을 갖춘 하드웨어에 필요한 PAE 모드를 제공한다. NX 하드웨어가 없는 시스템의 경우, 32비트 커널은 이제 공격자가 스택 또는 힙 메모리에서 실행할 수 있는 많은 익스플로잇을 차단하는 데 도움이 될 수 있는 소프트웨어 에뮬레이션을 통해 NX CPU 기능의 근사치를 제공한다.

실행 불가 기능은 또한 이 기능을 지원하는 다른 x86 외 프로세서에도 많은 릴리스에서 존재해왔다.

종종 NX 비트와 같은 하드웨어 기능을 이용한다. NX 비트는 AMD의 AMD64 시리즈 CPU에 탑재된다. 인텔 CPU (펜티엄 4의 프레스콧 코어 이후)의 XD 비트(eXecute Disable, EDB: Execute Disable Bit)도 동등한 기능이다. 썬의 SPARC, 알파, IBM의 파워PC 그리고 인텔의 IA-64(아이테니엄/머세드)의 일부에도 동등한 기능이 있다.

리눅스에서의 구현은 PaX나 Exec Shield, OpenBSD에서는 :en:W^X나 :en:Openwall 등이 있다.

Windows에서의 구현은 데이터 실행 방지('''DEP''')가 있다. DEP에는 하드웨어 DEP와 소프트웨어 DEP가 있으며, 하드웨어 DEP에서는 NX 비트 기능을 통해 데이터버퍼 내에 있는 코드의 실행을 금지한다. 소프트웨어 DEP에서는 이름은 유사하지만 그러한 기능(버퍼 오버런으로부터의 보호)은 없고, 대신 특정 공격(구조화된 예외 처리기 덮어쓰기)으로부터 보호한다.

기존의 응용 소프트웨어나 운영 체제와의 호환성, 보호 범위(응용 프로그램 전반까지, 운영 체제의 일부 기능만 등), 다양한 공격에 대한 취약성은 각 구현에 따라 다르다.

=== Exec Shield ===

레드햇 커널 개발자 잉고 몰나르(Ingo Molnár)는 32비트 x86 CPU에서 NX 기능을 근사하고 활용하기 위해 Exec Shield라는 이름의 리눅스 커널 패치를 공개했다. Exec Shield 패치는 2003년 5월 2일 리눅스 커널 메일링 리스트에 공개되었지만, 에뮬레이션의 복잡한 부분을 처리하기 위해 핵심 코드에 몇 가지 침투적인 변경 사항이 포함되어 있어 기본 커널에 병합되는 것이 거부되었다. Exec Shield의 레거시 CPU 지원은 상위 코드 세그먼트 제한을 추적하여 NX 에뮬레이션을 근사한다. 이는 컨텍스트 전환 중에 몇 사이클의 오버헤드만 부과하며, 이는 모든 의도와 목적에 따라 측정할 수 없다. NX 비트가 없는 레거시 CPU의 경우, Exec Shield는 코드 세그먼트 제한 아래의 페이지를 보호하지 못한다. 스택과 같은 상위 메모리를 실행 가능으로 표시하는 mprotect() 호출은 해당 제한 아래의 모든 메모리를 실행 가능으로 표시한다. 따라서 이러한 상황에서 Exec Shield의 방식은 실패한다. 이것이 Exec Shield의 낮은 오버헤드의 대가이다. Exec Shield는 ELF 헤더 마킹 두 가지를 확인하여 스택 또는 힙이 실행 가능해야 하는지 여부를 결정한다. 이를 각각 PT_GNU_STACK 및 PT_GNU_HEAP라고 한다. Exec Shield를 사용하면 바이너리 실행 파일과 라이브러리 모두에 대해 이러한 제어를 설정할 수 있다. 실행 파일이 주어진 제한 완화가 필요한 라이브러리를 로드하는 경우, 실행 파일은 해당 마킹을 상속받고 해당 제한이 완화된다.

  • 하드웨어 지원 프로세서: 리눅스가 NX를 지원하는 모든 프로세서
  • 에뮬레이션: IA-32(x86) 및 호환 가능한 CPU에서 코드 세그먼트 제한을 사용한 NX 근사
  • 기타 지원: 없음
  • 표준 배포판: 페도라 코어(Fedora Core) 및 레드햇 엔터프라이즈 리눅스(Red Hat Enterprise Linux)
  • 출시일: 2003년 5월 2일


=== PaX ===

PaX NX 기술은 NX 기능이나 하드웨어 NX 비트의 사용을 에뮬레이트 할 수 있다. PaX는 32비트 x86 같은 NX 비트를 갖지 않는 x86 CPU에서 동작한다. 리눅스 커널은 PaX를 포함하지 않아서 직접 패치할 수 밖에 없다.

PaX는 두 방식의NX 비트 에뮬레이션을 제공하는데, SEGMEXEC와 PAGEEXEC이 그것이다. SEGMEXEC 방식은 작은 오버헤드가 부과되며 일반적으로 1%미만이다. 이것은 실행과 데이터 접근 사이의 분리에 사용되는 가상 메모리 미러링 때문에 발생한다.[20] SEGMEXEC 또한 작업이 보통 보다 적은 메모리 접근을 허용하게 하는, 작업의 가상 주소 공간을 이등분하는 효과를 갖는다. 이것은 작업이 보통 주소 공간의 반 이상을 요구하기 전까지는 문제가 되지 않으며, 이런 일은 거의 일어나지 않는다. SEGMEXEC는 프로그램들이 더 많은 시스템 메모리(즉 RAM)를 사용하게 하지 않아서, 단지 그들이 얼마나 접근할 수 있는지만을 제한한다. 32비트 CPU에서, 이것은 1.5 GB가 된다.

PaX는 PAGEEXEC에서 속도를 높이기 위해 Exec Shield와 비슷한 방식을 제공한다. 그러나 높은 메모리가 실행 가능하게 마크되었을 때 이 방식은 보호를 잃는다. 이러한 경우에 PaX는 CS 제한 아래 페이지를 보호하기 위한 PAGEEXEC(특정한 메모리 접근 패턴에서 더 높은 오버헤드 동작이 될 수 있는)에 의해 사용되는 오래된 이전 방식의 변수-오버헤드 방식을 사용한다. PAGEEXEC 방식이 하드웨어 NX 비트를 제공하는 CPU에서 사용될 때, 하드웨어 NX 비트가 사용되어서 주목할 만한 오버헤드가 일어나지는 않는다.

PaX는 프로그램이 메모리를 마킹하는 것(잠재적인 익스플로잇에 유용한 방식으로)을 막는 mprotect() 제한을 제공한다. 이 정책은 특정한 애플리케이션의 기능을 막기도 하지만 감염된 프로그램을 비활성화할 수도 있다.

PaX는 아래에 나오는 각 실행 가능 바이너리를 위한 기술들의 기능들에 대한 각각의 제어를 허용한다.

  • PAGEEXEC
  • SEGMEXEC
  • mprotect() 제한
  • Trampoline 에뮬레이션
  • 난수화 실행 가능 베이스
  • 난수화 mmap() 베이스

PaX는 PT_GNU_STACK와 PT_GNU_HEAP를 무시한다. 과거에 PaX는 이러한 셋팅들을 고려하는 설정이 있었지만, 보안 상의 이유로 옵션이 제거되었다. PT_GNU_STACK의 같은 결과들도 일반적으로 mprotect() 제한을 비활성화함으로써 이루어질 수 있다(프로그램이 로드된 스택을 mprotect()할 것이다). 이것은 항상 참인 것은 아니다; 이것이 실패하는 경우 간단하게 PAGEEXEC와 SEGMEXEC를 비활성화하는 것은 효과적으로 모든 실행 가능 공간 제한들을 제거할 것이다.

2. 3. 1. Exec Shield

레드햇 커널 개발자 잉고 몰나르(Ingo Molnár)는 32비트 x86 CPU에서 NX 기능을 근사하고 활용하기 위해 Exec Shield라는 이름의 리눅스 커널 패치를 공개했다. Exec Shield 패치는 2003년 5월 2일 리눅스 커널 메일링 리스트에 공개되었지만, 에뮬레이션의 복잡한 부분을 처리하기 위해 핵심 코드에 몇 가지 침투적인 변경 사항이 포함되어 있어 기본 커널에 병합되는 것이 거부되었다. Exec Shield의 레거시 CPU 지원은 상위 코드 세그먼트 제한을 추적하여 NX 에뮬레이션을 근사한다. 이는 컨텍스트 전환 중에 몇 사이클의 오버헤드만 부과하며, 이는 모든 의도와 목적에 따라 측정할 수 없다. NX 비트가 없는 레거시 CPU의 경우, Exec Shield는 코드 세그먼트 제한 아래의 페이지를 보호하지 못한다. 스택과 같은 상위 메모리를 실행 가능으로 표시하는 mprotect() 호출은 해당 제한 아래의 모든 메모리를 실행 가능으로 표시한다. 따라서 이러한 상황에서 Exec Shield의 방식은 실패한다. 이것이 Exec Shield의 낮은 오버헤드의 대가이다. Exec Shield는 ELF 헤더 마킹 두 가지를 확인하여 스택 또는 힙이 실행 가능해야 하는지 여부를 결정한다. 이를 각각 PT_GNU_STACK 및 PT_GNU_HEAP라고 한다. Exec Shield를 사용하면 바이너리 실행 파일과 라이브러리 모두에 대해 이러한 제어를 설정할 수 있다. 실행 파일이 주어진 제한 완화가 필요한 라이브러리를 로드하는 경우, 실행 파일은 해당 마킹을 상속받고 해당 제한이 완화된다.

  • 하드웨어 지원 프로세서: 리눅스가 NX를 지원하는 모든 프로세서
  • 에뮬레이션: IA-32(x86) 및 호환 가능한 CPU에서 코드 세그먼트 제한을 사용한 NX 근사
  • 기타 지원: 없음
  • 표준 배포판: 페도라 코어(Fedora Core) 및 레드햇 엔터프라이즈 리눅스(Red Hat Enterprise Linux)
  • 출시일: 2003년 5월 2일

2. 3. 2. PaX

PaX NX 기술은 NX 기능이나 하드웨어 NX 비트의 사용을 에뮬레이트 할 수 있다. PaX는 32비트 x86 같은 NX 비트를 갖지 않는 x86 CPU에서 동작한다. 리눅스 커널은 PaX를 포함하지 않아서 직접 패치할 수 밖에 없다.

PaX는 두 방식의NX 비트 에뮬레이션을 제공하는데, SEGMEXEC와 PAGEEXEC이 그것이다. SEGMEXEC 방식은 작은 오버헤드가 부과되며 일반적으로 1%미만이다. 이것은 실행과 데이터 접근 사이의 분리에 사용되는 가상 메모리 미러링 때문에 발생한다.[20] SEGMEXEC 또한 작업이 보통 보다 적은 메모리 접근을 허용하게 하는, 작업의 가상 주소 공간을 이등분하는 효과를 갖는다. 이것은 작업이 보통 주소 공간의 반 이상을 요구하기 전까지는 문제가 되지 않으며, 이런 일은 거의 일어나지 않는다. SEGMEXEC는 프로그램들이 더 많은 시스템 메모리(즉 RAM)를 사용하게 하지 않아서, 단지 그들이 얼마나 접근할 수 있는지만을 제한한다. 32비트 CPU에서, 이것은 1.5 GB가 된다.

PaX는 PAGEEXEC에서 속도를 높이기 위해 Exec Shield와 비슷한 방식을 제공한다. 그러나 높은 메모리가 실행 가능하게 마크되었을 때 이 방식은 보호를 잃는다. 이러한 경우에 PaX는 CS 제한 아래 페이지를 보호하기 위한 PAGEEXEC(특정한 메모리 접근 패턴에서 더 높은 오버헤드 동작이 될 수 있는)에 의해 사용되는 오래된 이전 방식의 변수-오버헤드 방식을 사용한다. PAGEEXEC 방식이 하드웨어 NX 비트를 제공하는 CPU에서 사용될 때, 하드웨어 NX 비트가 사용되어서 주목할 만한 오버헤드가 일어나지는 않는다.

PaX는 프로그램이 메모리를 마킹하는 것(잠재적인 익스플로잇에 유용한 방식으로)을 막는 mprotect() 제한을 제공한다. 이 정책은 특정한 애플리케이션의 기능을 막기도 하지만 감염된 프로그램을 비활성화할 수도 있다.

PaX는 아래에 나오는 각 실행 가능 바이너리를 위한 기술들의 기능들에 대한 각각의 제어를 허용한다.

  • PAGEEXEC
  • SEGMEXEC
  • mprotect() 제한
  • Trampoline 에뮬레이션
  • 난수화 실행 가능 베이스
  • 난수화 mmap() 베이스

PaX는 PT_GNU_STACK와 PT_GNU_HEAP를 무시한다. 과거에 PaX는 이러한 셋팅들을 고려하는 설정이 있었지만, 보안 상의 이유로 옵션이 제거되었다. PT_GNU_STACK의 같은 결과들도 일반적으로 mprotect() 제한을 비활성화함으로써 이루어질 수 있다(프로그램이 로드된 스택을 mprotect()할 것이다). 이것은 항상 참인 것은 아니다; 이것이 실패하는 경우 간단하게 PAGEEXEC와 SEGMEXEC를 비활성화하는 것은 효과적으로 모든 실행 가능 공간 제한들을 제거할 것이다.

2. 4. macOS

macOS는 인텔 기반에서 애플이 지원하는 모든 CPU (Mac OS X 10.4.4부터 – 최초의 인텔 출시 버전 – 이후)에서 NX 비트를 지원한다. Mac OS X 10.4는 NX 스택 보호만 지원했다. Mac OS X 10.5에서는 모든 64비트 실행 파일이 NX 스택 및 힙, W^X 보호 기능을 갖추고 있다. 여기에는 x86-64 (Core 2 이상) 및 G5 맥의 64비트 PowerPC가 포함된다.

2. 5. NetBSD

NetBSD 2.0 버전 (2004년 12월 9일) 이상부터 이를 지원하는 아키텍처는 실행 불가능한 스택과 힙을 갖는다.[6]

페이지 단위로 세분화된 아키텍처는 다음과 같다: 알파, amd64, hppa, i386 (PAE 포함), powerpc (ibm4xx), sh5, sparc (sun4m, sun4d), sparc64. 영역 단위로만 지원하는 아키텍처는 다음과 같다: i386 (PAE 미포함), 기타 powerpc (macppc 등). 기타 아키텍처는 실행 불가능한 스택 또는 힙의 이점을 누릴 수 없다. NetBSD는 기본적으로 이러한 아키텍처에서 이러한 기능을 제공하기 위해 소프트웨어 에뮬레이션을 사용하지 않는다.

종종 NX 비트와 같은 하드웨어 기능을 이용한다. NX 비트는 AMD의 AMD64 시리즈 CPU에 탑재된다. 인텔 CPU (펜티엄 4의 프레스콧 코어 이후)의 XD 비트(eXecute Disable, EDB: Execute Disable Bit)도 동등한 기능이다. 썬의 SPARC, 알파, IBM의 파워PC 그리고 인텔의 IA-64(아이테니엄/머세드)의 일부에도 동등한 기능이 있다.

2. 6. OpenBSD

OpenBSD 운영 체제의 기술인 W^X는 이를 지원하는 프로세서에서 기본적으로 쓰기 가능한 페이지를 실행 불가능으로 표시한다. 32비트 x86 프로세서에서 코드 세그먼트는 주소 공간의 일부만 포함하도록 설정되어 실행 가능 공간 보호 수준을 제공한다.

2003년 5월 1일에 출시된 OpenBSD 3.3은 W^X를 처음으로 포함했다. W^X는 종종 NX 비트와 같은 하드웨어 기능을 이용한다. NX 비트는 AMD의 AMD64 시리즈 CPU에 탑재된다. 인텔 CPU (펜티엄 4의 프레스콧 코어 이후)의 XD 비트(eXecute Disable, EDB: Execute Disable Bit)도 동등한 기능이다. 썬의 SPARC, 알파, IBM의 파워PC 그리고 인텔의 IA-64(아이테니엄/머세드)의 일부에도 동등한 기능이 있다.

  • 지원 하드웨어 프로세서: 알파, AMD64, HPPA, SPARC
  • 에뮬레이션: IA-32 (x86)

2. 7. 솔라리스

솔라리스는 솔라리스 2.6(1997년)부터 SPARC 프로세서에서 스택 실행을 전역적으로 비활성화하는 것을 지원해 왔으며, 솔라리스 9(2002년)에서는 실행 파일별로 스택 실행을 비활성화하는 기능이 추가되었다. 종종 NX 비트와 같은 하드웨어 기능을 이용한다. NX 비트는 AMD의 AMD64 시리즈 CPU에 탑재된다. 인텔 CPU (펜티엄 4의 프레스콧 코어 이후)의 XD 비트(eXecute Disable, EDB: Execute Disable Bit)도 동등한 기능이다. 썬의 SPARC, 알파, IBM의 파워PC 그리고 인텔의 IA-64(아이테니엄/머세드)의 일부에도 동등한 기능이 있다.

2. 8. 윈도우

윈도우 XP 서비스 팩 2 (2004)와 윈도우 서버 2003 서비스 팩 1 (2005)를 시작으로, NX 특징들이 x86 아키텍처에서 처음으로 구현되었다.[7][8] 윈도우에서의 실행 가능 공간 보호는 "데이터 실행 방지(DEP)"라고 불린다.

윈도우 XP 또는 서버 2003 하에서 NX 보호는 중요한 윈도우 서비스에서 배타적으로 기본 옵션으로 사용되었다. 만약 x86 프로세서가 이 특징을 지원한다면 NX 특징은 기본적으로 자동으로 설정된다.

주소 공간 배치 난수화(ASLR) 없이 제공된 초기의 DEP는 잠재적인 return-to-libc 공격을 허용하였고 공격 동안 쉽게 DEP를 비활성화 할 수 있었다.[9] PaX 문서는 왜 ASLR이 필요한지를 상술하였다.[10] ASLR가 없는 환경에서 DEP에 가능한 개념 증명이 만들어졌다.[11] 이것은 오염된 이미지 같은 준비된 데이터의 주소가 공격자에게 알려질 수 있다는 것이다.

마이크로소프트는 윈도우 비스타와 윈도우 서버 2008에 ASLR 기능을 추가하였다. 이 플랫폼에서는 DEP는 PAE 커널의 자동화된 사용을 통해 구현되었다. 윈도우 비스타 DEP는 메모리의 특정한 영역을 오직 데이터만 갖게 의도함으로써 동작한다. 이로써 NX 또는 XD 비트가 프로세서를 활성화하고 실행 불가하다고 알려진다.[12] 비스타 이후의 윈도우에서 DEP가 활성화되었든지 말든지 간에 특정한 프로세스는 윈도우 작업 관리자의 프로세스 탭에서 볼 수 있다.

윈도우는 마이크로소프트의 "Safe Structured Exception Handling"(SafeSEH)을 통해 소프트웨어 DEP(NX 비트의 사용 없이)를 구현하였다. 적절하게 컴파일된 애플리케이션에서 프로그램 실행 중에 예외가 일어나면 SafeSEH는 예외 처리기가 원본에서 컴파일 된 것인지를 검사한다. 이 보호의 효과는 공격자가 자신의 예외 핸들러(데이터 페이지에 저장하거나 검사되지 않은 프로그램 입력을 통한)를 추가하지 못하게 하는 것이다.[12][13]

NX가 지원되면, 기본값으로 활성화 된다. 윈도우는 프로그램이 API나 PE 파일의 섹션 헤더를 통해 어떤 페이지를 실행 불가하게 하는 것을 허용한다. API에서 NX 비트에 대한 런타임 접근은 Win32 API 호출인 '''VirtualAlloc[Ex]'''와 '''VirtualProtect[Ex]'''를 통해 가능하다. 각페이지는 각각 실행 가능이거나 불가로 플래그될 수 있다. 이전의 x86 하드웨어 지원의 부족에도 불구하고, 실행 가능 그리고 불가 페이지 셋팅들 모두 시작 시에 제공된다. NX 이전의 CPU는 'executable' 속성이 영향을 미치지 않는다. 이것은 대부분의 프로그래머들이 적절하게 사용할 수 있게 문서화되어 있다. PE 파일 포맷에서, 각 섹션은 자신의 실행 가능함을 명시할 수 있다. 실행 플래그가 존재해서 시작 시에 표준 링커가 NX 비트 전에 이것을 사용한다. 이것 때문에 윈도우는 NX 비트를 오래된 프로그램에 강제할 수 있다.

2. 9. Xbox

마이크로소프트의 Xbox에서 CPU는 NX 비트를 가지고 있지 않지만, 최신 버전의 XDK는 코드 세그먼트 제한을 커널의 '''.data''' 섹션 시작점으로 설정한다. (정상적인 상황에서는 이 지점 뒤에 코드가 없어야 한다). 버전 51xx부터 이 변경 사항은 새로운 Xbox의 커널에도 구현되었다. 이는 이전 익스플로잇이 상주 프로그램이 되기 위해 사용했던 기술을 무력화시켰다. 그러나 Xbox 커널의 근본적인 취약점은 영향을 받지 않았기 때문에 이 새로운 커널 버전을 지원하는 새로운 익스플로잇이 빠르게 공개되었다.

3. 한계

JIT 컴파일 같은 런타임에 코드가 작성되고 실행되는 곳에서 컴파일러는 JIT 스프레이를 통해 익스플로잇 코드를 만드는 데 사용될 수 있다.[26][27][14][15] ROP는 공격자가 실행 가능 공간 보호가 적용된 경우에도 임의의 코드를 실행할 수 있도록 한다.

4. 대한민국의 관점

참조

[1] 간행물 Memory Management Security Enhancements http://source.androi[...] Android Security Overview 2012-07-29
[2] 웹사이트 Android code change enabling NX by default. https://android.goog[...] 2019-08-27
[3] 웹사이트 Android Compatibility Requirement for NX https://android-revi[...] 2019-08-27
[4] 웹사이트 Linux kernel 2.6.8 http://kernelnewbies[...] 2004-08-14
[5] 웹사이트 PaX SEGMEXEC documentation https://pax.grsecuri[...] 2015-01-25
[6] 간행물 Non-executable stack and heap http://www.netbsd.or[...] NetBSD 2011-07-14
[7] 웹사이트 SecureWave {{!}} SecureNT https://web.archive.[...] 2023-12-27
[8] 웹사이트 Homepage of PaX - the PAGE_EXEC flag implementation for IA-32 https://web.archive.[...] 2023-12-27
[9] 웹사이트 Blog on Cyberterror https://web.archive.[...] 2008-01-08
[10] 웹사이트 address space layout randomization http://pax.grsecurit[...]
[11] 웹사이트 Uninformed - vol 2 article 4 https://web.archive.[...] 2010-03-19
[12] 웹사이트 A detailed description of the Data Execution Prevention (DEP) feature in Windows XP Service Pack 2, Windows XP Tablet PC Edition 2005, and Windows Server 2003 http://support.micro[...] Microsoft 2008-07-11
[13] 웹사이트 Yasm User Manual, win32: Safe Structured Exception Handling https://web.archive.[...] 2015-09-27
[14] 웹사이트 Interpreter Exploitation: Pointer Inference And JIT Spraying http://www.semantisc[...]
[15] 웹사이트 Writing JIT-Spray Shellcode for fun and profit http://dsecrg.com/fi[...] 2010-03-05
[16] 간행물 Memory Management Security Enhancements http://source.androi[...] Android Security Overview 2012-07-29
[17] 간행물 Android code change forcing NX http://android.git.k[...] Android Source Repository Change 2011-07-14
[18] 간행물 Android Compatibility Requirement for NX https://review.sourc[...] Android Code Review 2011-07-14
[19] 웹인용 Linux kernel 2.6.8 http://kernelnewbies[...] 2015-08-01
[20] 웹인용 PaX SEGMEXEC documentation https://web.archive.[...] 2015-01-25
[21] 웹인용 Blog on Cyberterror http://woct-blog.blo[...] 2016-03-19
[22] 문서 http://pax.grsecurit[...]
[23] 웹인용 Uninformed - vol 2 article 4 https://web.archive.[...] 2016-03-19
[24] 웹인용 A detailed description of the Data Execution Prevention (DEP) feature in Windows XP Service Pack 2, Windows XP Tablet PC Edition 2005, and Windows Server 2003 http://support.micro[...] 마이크로소프트 2008-07-11
[25] 웹인용 Yasm User Manual, win32: Safe Structured Exception Handling http://www.tortall.n[...] 2015-09-27
[26] 웹인용 Interpreter Exploitation: Pointer Inference And JIT Spraying http://www.semantisc[...]
[27] 문서 Writing JIT-Spray Shellcode for fun and profit http://dsecrg.com/fi[...]


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com