실행 가능한 공간 보호

Executable space protection

컴퓨터 보안에서 실행 가능한 공간 보호메모리 영역을 실행 불가능으로 표시하여 이러한 영역에서 컴퓨터 코드를 실행하려고 하면 예외가 발생하게 된다.그것은 NX 비트(비실행 비트)와 같은 하드웨어 기능이나 경우에 따라 그러한 기능의 소프트웨어 에뮬레이션과 같은 기능을 사용한다.그러나 NX 비트를 에뮬레이트하거나 공급하는 기술은 일반적으로 측정 가능한 오버헤드를 부과하는 반면, 하드웨어 공급 NX 비트를 사용하면 측정 가능한 오버헤드가 부과되지 않는다.

버러우스 5000은 1961년 도입 당시 실행 가능한 공간 보호를 위한 하드웨어 지원을 제공했으며, 그 기능은 최소한 2006년까지 후계자 자리를 지켰다.태그가 붙은 구조의 구현에서, 메모리의 각 단어는 그것을 코드나 데이터로 지정하는 연관된 숨겨진 태그 비트를 가지고 있었다.따라서 사용자 프로그램은 프로그램 단어를 쓰거나 읽을 수 없으며 데이터 단어는 실행될 수 없다.

운영 체제가 쓰기 가능한 일부 또는 모든 메모리 영역을 실행 불가로 표시할 수 있는 경우 스택 및 힙 메모리 영역이 실행되지 않도록 방지할 수 있다.이것은 특히 SasserBlaster 웜과 같은 코드를 주입하고 실행하는 버퍼 오버플로우 공격이 성공하는 것을 방지하는 데 도움이 된다.이러한 공격은 대개 스택의 메모리 일부에 의존하며 쓰기 가능하거나 실행 가능하지 않으면 공격이 실패한다.

OS 구현

많은 운영 체제가 실행 가능한 공간 보호 정책을 구현하거나 보유하고 있다.다음은 알파벳 순으로 정렬된 그러한 시스템의 목록이며, 각각 최신 기술부터 오래된 기술까지 포함되어 있다.

일부 기술의 경우, 각 기술이 지원하는 주요 특징을 요약하여 제공한다.요약은 아래와 같이 구성된다.

  • 하드웨어 지원 프로세서: (콤마로 구분된 CPU 아키텍처 목록)
  • 에뮬레이션: (No) 또는 (Architecture Independent) 또는 (Comma로 구분된 CPU 아키텍처 목록)
  • 기타 지원: (없음) 또는 (콤마로 구분된 CPU 아키텍처 목록)
  • 표준 배포: (아니오) 또는 (예) 또는 (기술을 지원하는 배포 또는 버전의 콤마로 구분된 목록)
  • 릴리스 날짜: (첫 번째 릴리스 날짜)

Architecture Independent 에뮬레이션을 제공하는 기술은 하드웨어가 지원되지 않는 모든 프로세서에서 기능할 것이다."Other Supported" 라인은 명시적 NX 비트가 존재하지 않지만 하드웨어가 어떤 방식으로든 에뮬레이션을 허용하는 회색 영역 방식을 허용하는 프로세서를 위한 것이다.

안드로이드

Android 2.3 이상에서, 그것을 지원하는 아키텍처는 기본적으로 실행 불가능한 스택과 힙을 포함한 실행 불가능한 페이지를 가지고 있다.[1] [2] [3]

자유BSD

NX 비트를 지원하는 x86-64 및 IA-32 프로세서에 대한 초기 지원은 2004년 6월 8일 FreeBSD -CURRENT에 처음 등장했다.그것은 FreeB에 있었다.5.3 릴리스 이후 SD 릴리스.

리눅스

리눅스 커널은 AMD, 인텔, 트랜스메타, VIA가 만든 현대식 64비트 프로세서 등 이를 지원하는 iA-32 프로세서와 x86-64에서 NX비트를 지원한다.x86-64 CPU의 64비트 모드에서 이 기능에 대한 지원은 2004년 Andi Kleen에 의해 추가되었고, 같은 해 후반에는 Ingo Molnar가 64비트 CPU의 32비트 모드로 지원을 추가하였다.이러한 기능은 2004년 8월 커널 버전 2.6.8이 출시된 이후 리눅스 커널 메인라인의 일부가 되었다.[4]

The availability of the NX bit on 32-bit x86 kernels, which may run on both 32-bit x86 CPUs and 64-bit IA-32-compatible CPUs, is significant because a 32-bit x86 kernel would not normally expect the NX bit that an AMD64 or IA-64 supplies; the NX enabler patch assures that these kernels will attempt to use the NX bit if present.

Fedora, UbuntuOpen과 같은 일부 데스크톱 Linux 배포SUSE, do not enable the HIGHMEM64 option by default in their default kernels, which is required to gain access to the NX bit in 32-bit mode, because the PAE mode that is required to use the NX bit causes boot failures on pre-Pentium Pro (including Pentium MMX) and Celeron M and Pentium M processors without NX support.PAE를 지원하지 않는 다른 프로세서는 AMD K6 이하, Transmeta Crusoe, VIA C3 이하, Geode GX 및 LX. 4.0 이전 버전의 VMware Workstation, 4.0 이전 버전의 Parallels Workstation 및 Microsoft Virtual PC와 Virtual Server가 게스트에서 PAE를 지원하지 않는다.Fedora Core 6와 Ubuntu 9.10 이상은 PAE와 NX를 지원하는 커널-PAE 패키지를 제공한다.

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

많은 릴리스에서 이 기능을 지원하는 다른 비 x86 프로세서에도 비실행 기능이 존재했다.

Exec Shield

Red Hat 커널 개발자 Ingo Molnar32비트 x86 CPU에 NX 기능을 근사하게 활용하고 활용하기 위해 Exec Shield라는 리눅스 커널 패치를 출시했다.Exec Shield 패치는 2003년 5월 2일 Linux 커널 메일링 리스트에 공개되었지만 에뮬레이션의 복잡한 부분을 처리하기 위해 코어 코드에 대한 일부 침입적 변경이 포함되었기 때문에 기본 커널과의 병합이 거부되었다.Exec Shield의 레거시 CPU 지원은 상위 코드 세그먼트 제한을 추적하여 NX 에뮬레이션에 가깝다.이것은 컨텍스트 전환 중에 단지 몇 사이클의 오버헤드를 부과하는데, 이것은 모든 개념과 목적을 측정할 수 없다.NX 비트가 없는 레거시 CPU의 경우, Exec Shield는 코드 세그먼트 제한 이하의 페이지를 보호하지 못한다. 스택과 같은 더 높은 메모리를 표시하기 위한 mprotect() 호출은 실행 파일 제한 아래의 모든 메모리도 표시한다.따라서 이러한 상황에서 Exec Shield의 계획은 실패한다.이것은 Exec Shield의 낮은 오버헤드 비용이다.Exec Shield는 스택 또는 힙을 실행해야 하는지 여부를 지시하는 두 개의 ELF 헤더 표시를 검사한다.이를 각각 PT_GNU_SACK, PT_GNU_HEAP라고 한다.Exec Shield는 이러한 제어를 이진 실행 파일과 라이브러리에 대해 모두 설정할 수 있도록 허용한다. 실행 파일이 주어진 제한을 완화하는 라이브러리를 로드할 경우 실행 파일이 해당 표시를 상속하고 해당 제한을 완화할 수 있다.

PAX

PaX NX 기술은 NX 기능을 모방하거나 하드웨어 NX 비트를 사용할 수 있다.PaX는 32비트 x86과 같이 NX 비트가 없는 x86 CPU에서 작동한다.리눅스 커널은 여전히 PaX(2007년 5월 기준)와 함께 제공되지 않으므로 패치는 수동으로 병합해야 한다.

PaX는 SEGMEXEC와 PAGEXEC라고 불리는 NX 비트 에뮬레이션의 두 가지 방법을 제공한다.SEGMEXEC 방법은 측정 가능하지만 낮은 오버헤드를 부과하는데, 이는 실행과 데이터 액세스 사이의 분리에 사용되는 가상 메모리 미러링으로 인해 발생하는 지속적인 스칼라이다.[5]또한 SEGMEXEC는 태스크의 가상 주소 공간을 절반으로 줄여 태스크가 보통보다 적은 메모리에 액세스할 수 있도록 하는 효과가 있다.이 작업은 드물게 일반 주소 공간의 절반 이상을 액세스해야 하기 전까지는 문제가 되지 않는다.SEGMEXEC은 프로그램이 더 많은 시스템 메모리(즉, RAM)를 사용하도록 하지 않으며, 그들이 접근할 수 있는 양만 제한한다.32비트 CPU에서는 3GB가 아닌 1.5GB가 된다.

PaX는 PAGEEXEC에서 Exec Shield의 근사치와 유사한 방법을 속도 향상으로 제공하지만, 더 높은 메모리가 실행 가능한 것으로 표시되면 이 방법은 보호 기능을 상실한다.이 경우 PAX는 페이지EXEC가 CS 한계 이하의 페이지를 보호하기 위해 사용하는 이전의 가변 오버헤드 방식으로 되돌아가는데, 이는 특정 메모리 액세스 패턴에서 상당히 높은 오버헤드 작업이 될 수 있다.하드웨어 NX 비트를 공급하는 CPU에 PAGEXEC 방법을 사용하면 하드웨어 NX 비트가 사용되므로 상당한 오버헤드가 발생하지 않는다.

PaX는 프로그램이 잠재적인 공격에 유용한 메모리를 생성하는 방법으로 메모리를 표시하는 것을 방지하기 위해 mprotect() 제한을 제공한다.이 정책은 특정 응용 프로그램이 작동을 멈추게 하지만 영향을 받는 프로그램에서는 비활성화할 수 있다.

PaX는 각 이진 실행 파일에 대해 다음과 같은 기술의 기능에 대한 개별 제어를 허용한다.

  • 페이지EXEC
  • 세GMEXEC
  • mprotected 제한
  • 트램펄린 에뮬레이션
  • 임의화된 실행 파일 기반
  • 랜덤화 mmap() 베이스

PaX는 PT_GNU_STACK과 PT_GNU_HEAP를 모두 무시한다.과거에 PaX는 이러한 설정을 준수하는 구성 옵션을 가지고 있었지만, 이 옵션은 유용하지 않다고 판단되어 보안상의 이유로 제거되었다.프로그램이 일반적으로 로드 시 스택을 mprotect()하는 것처럼 PT_GNU_STACK의 동일한 결과는 mprotect() 제한을 비활성화하여 얻을 수 있다.이는 항상 사실이 아닐 수 있다. 이 오류가 발생하는 상황에서 PAGEEXEC와 SEGMEXEC를 모두 비활성화하기만 하면 모든 실행 공간 제한이 효과적으로 제거되어 작업이 비 PaX 시스템과 동일한 실행 공간 보호 기능을 제공하게 된다.

마코스

Intel용 MacOS는 Apple에서 지원하는 모든 CPU에서 NX 비트를 지원한다(Mac OS X 10.4.4 – 첫 번째 Intel 릴리즈 – 그 이후).Mac OS X 10.4는 NX 스택 보호만 지원했다.Mac OS X 10.5에서 모든 64비트 실행 파일에는 NX 스택 및 힙, W^X 보호 기능이 있다.여기에는 G5 Mac의 x86-64(Core 2 이상)와 64비트 PowerPC가 포함된다.

넷BSD

NetBSD 2.0 이상(2004년 12월 9일)을 기준으로, 이를 지원하는 아키텍처에는 실행 불가능한 스택과 힙이 있다.[6]

페이지당 세분성을 갖는 아키텍처는 알파, amd64, hpa, i386(PAE 포함), powerpc(ibm4xx), sh5, sparc(sun4m, sun4d), sparc64로 구성된다.

지역 세분화로만 이를 지원할 수 있는 아키텍처는 i386(PAE 제외), 기타 powerpc(macppc 등)이다.

다른 아키텍처들은 실행 불가능한 스택이나 힙으로부터 이익을 얻지 못한다. NetBSD는 기본적으로 이러한 아키텍처에 이러한 기능을 제공하기 위해 어떠한 소프트웨어 에뮬레이션을 사용하지 않는다.

오픈BSD

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

오픈BSD 3.3은 2003년 5월 1일에 선적되었으며, W^X를 최초로 포함하였다.

  • 하드웨어 지원 프로세서:알파, AMD64, HPA, SPARC
  • 에뮬레이션: IA-32(x86)
  • 기타 지원:없음
  • 표준 분포:
  • 릴리스 날짜:2003년 5월 1일

솔라리스

Solaris는 Solaris 2.6(1997) 이후 SPARC 프로세서에서 스택 실행을 전세계적으로 비활성화하는 것을 지원해왔으며, Solaris 9(2002)에서는 실행 가능한 기준으로 스택 실행을 비활성화하는 지원이 추가되었다.

창문들

윈도 XP 서비스 팩 2(2004)와 윈도 서버 2003 서비스 팩 1(2005)을 시작으로, NX 기능이 x86 아키텍처에서 처음으로 구현되었다.Windows에서 실행 가능한 공간 보호를 "DEP(Data Execution Prevention)"라고 한다.

Windows XP 또는 Server 2003 NX 보호는 기본적으로 중요한 Windows 서비스에 독점적으로 사용되었다.x86 프로세서가 하드웨어에서 이 기능을 지원했다면, NX 기능은 기본적으로 Windows XP/Server 2003에서 자동으로 켜졌다.이 기능이 x86 프로세서에 의해 지원되지 않는 경우 보호가 제공되지 않았다.

DEP의 초기 구현은 어드레스 공간 배치 무작위화(ASLR)를 제공하지 않았으며, 이는 공격 중 DEP를 비활성화하는 데 타당하게 사용될 수 있는 잠재적 리턴-libc 공격을 허용했다.[7]PaX 문서에서는 ASLR이 필요한 이유를 상세히 설명하고 있다.[8] ASLR이 없을 때 DEP를 우회할 수 있는 방법을 상세히 설명하는 개념 증명서가 작성되었다.[9]공격자가 손상된 이미지나 MP3와 같은 준비된 데이터의 주소를 알 수 있다면 성공적인 공격을 전개할 수 있을 것이다.

Microsoft는 Windows VistaWindows Server 2008에서 ASLR 기능을 추가했다.이 플랫폼에서는 32비트 윈도에서의 PAE 커널의 자동 사용과 64비트 커널에서의 네이티브 지원을 통해 DEP가 구현된다.Windows Vista DEP는 메모리의 특정 부분을 데이터만 저장하기 위한 것으로 표시하여 작동하며, NX 또는 XD 비트 활성화 프로세서가 이를 실행 불가능으로 이해한다.[10]Windows(윈도우)의 버전 Vista에서 특정 프로세스에 대해 DEP를 사용할 수 있는지 여부를 Windows(윈도우) 작업 관리자의 프로세스/세부 정보 탭에서 볼 수 있다.

Windows는 Microsoft의 "SafeSEH"(SafeSeH)를 통해 (NX 비트를 사용하지 않고) 소프트웨어 DEP를 구현한다.적절하게 컴파일된 응용 프로그램의 경우, SafeSEH는 프로그램 실행 중에 예외가 제기되었을 때, 예외의 처리기가 원래 컴파일된 응용 프로그램에 의해 정의된 핸들러인지 점검한다.이 보호의 효과는 공격자가 데이터 페이지에 저장한 자신의 예외 핸들러를 체크되지 않은 프로그램 입력을 통해 추가할 수 없다는 것이다.[10][11]

NX가 지원되면 기본적으로 활성화된다.Windows(윈도우)에서는 프로그램이 PE 파일의 섹션 헤더뿐만 아니라 API를 통해 실행을 허용하지 않는 페이지를 제어할 수 있다.API에서는 Win32 API 호출 VirtualAlloc[Ex]VirtualProtect[Ex]를 통해 NX 비트에 대한 런타임 액세스가 노출된다.각 페이지는 개별적으로 실행 가능 또는 실행 불가능으로 플래그 지정될 수 있다.이전의 x86 하드웨어 지원이 없음에도 불구하고 실행 가능 페이지 설정과 실행 불가능 페이지 설정은 모두 처음부터 제공되어 왔다.NX 이전 CPU에서는 '실행 가능' 속성의 존재는 영향을 미치지 않는다.그것은 마치 작동한 것처럼 기록되었고, 그 결과 대부분의 프로그래머들이 그것을 적절하게 사용했다.PE 파일 형식에서 각 섹션은 실행 가능성을 지정할 수 있다.실행 플래그는 포맷이 시작된 이후로 존재해왔고 표준 링크업자는 NX 비트 이전에도 항상 이 플래그를 정확하게 사용했다.이 때문에 윈도우는 구형 프로그램에 NX비트를 강제할 수 있다.프로그래머가"모범 사례"를준수했다고 가정할 때, NX가 실제로 시행되고 있는 지금 응용 프로그램은 올바르게 작동해야 한다.단지 몇몇 경우에 문제가 있었다; 마이크로소프트 사의 것이다.NET Runtime은 NX 비트에 문제가 있어 업데이트되었다.

엑스박스

Microsoft의 Xbox에서 CPU에 NX 비트가 없지만 XDK의 최신 버전은 코드 세그먼트 제한을 커널의 .data 섹션의 시작 부분으로 설정한다(정상 상황에서는 이 시점 이후가 되지 않아야 한다).51xx 버전부터, 이러한 변화는 새로운 Xbox의 커널에도 구현되었다.이것은 TSR이 되기 위해 사용되었던 오래된 기술들을 깨뜨렸다.그러나 Xbox 커널의 근본적인 취약성은 영향을 받지 않았기 때문에 이 새로운 커널 버전을 지원하는 새로운 공격들이 빠르게 발표되었다.

제한 사항

코드가 실행될 때 작성되고 실행될 경우(JIT 컴파일러가 대표적인 예임) 컴파일러는 실행 플래그가 지정되어 실행되지 않는 취약성 코드(예:[12][13] JIT 스프레이 사용)를 생성하는 데 잠재적으로 사용될 수 있다.

반환 지향 프로그래밍은 실행 가능한 공간 보호가 시행된 경우에도 공격자가 임의 코드를 실행할 수 있도록 할 수 있다.

참고 항목

참조

  1. ^ "메모리 관리 보안 향상", Android 보안 개요, 2012/07/29 검색
  2. ^ "Android code change enabling NX by default". Android Source Repository Change. Retrieved 2019-08-27.
  3. ^ "Android Compatibility Requirement for NX". Android Code Review. Retrieved 2019-08-27.
  4. ^ "Linux kernel 2.6.8". kernelnewbies.org. 2004-08-14. Retrieved 2015-08-01.
  5. ^ "PaX SEGMEXEC documentation" (TXT). pax.grsecurity.net. September 10, 2004. Retrieved January 25, 2015.
  6. ^ NetBSD, 실행 불가능한 스택 , 2011/07/14 검색.
  7. ^ "Blog on Cyberterror".
  8. ^ http://pax.grsecurity.net/docs/aslr.txt
  9. ^ "Uninformed - vol 2 article 4". Archived from the original on 2016-03-12. Retrieved 2010-03-19.
  10. ^ a b "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". Microsoft. 2006-09-26. Archived from the original on 2014-09-11. Retrieved 2008-07-11.
  11. ^ Johnson, Peter. "Yasm User Manual, win32: Safe Structured Exception Handling". Tortall Networks: Open Source and Free Software. Archived from the original on January 2, 2015. Retrieved 27 September 2015.
  12. ^ Dion Blazakis. "Interpreter Exploitation: Pointer Inference And JIT Spraying" (PDF).
  13. ^ Alexey Sintsov (March 5, 2010). "Writing JIT-Spray Shellcode for fun and profit" (PDF). Archived from the original (PDF) on 2016-03-04.