Exec Shield
Exec Shield는 2002년 리눅스 시스템에 대한 웜 또는 다른 자동화된 원격 공격들을 줄이기 위한 목표로 레드햇 사에서 시작된 프로젝트이다. 이 프로젝트의 첫 번째 결과는 하드웨어에서 네이티브 NX 구현이 없는 x86 CPU에서 NX 비트를 에뮬레이팅하는 리눅스 커널의 보안 패치였다. Exec Shield 프로젝트가 여러 다른 구성 요소들을 가지지만 어떤 사람들은 이 첫 번째 패치를 Exec Shield로 부르기도 한다.
첫 번째 Exec Shield 패치는 데이터 메모리를 실행 불가능하게 그리고 프로그램 메모리를 쓰기 불가능하게 플래그하려는 시도였다. 이것은 버퍼 오버플로 같이 데이터를 겹쳐쓰고 이러한 구조에 코드를 삽입하는 것을 기반으로하는 많은 취약점 공격을 제한하였다. Exec Shield는 또한 mmap()과 힙 베이스를 위한 몇몇 주소 공간 배치 난수화를 제공한다.
패치는 추가적으로 셸코드를 삽입하고 실행하는 난이도를 증가시켜 대부분의 익스플로잇을 막았다. exec-shield를 완전히 활용하기 위한 애플리케이션의 재컴파일은 필요하지 않지만, 몇몇 애플리케이션들(모노, 와인, XEmacs, 엠플레이어)은 완전히 호환되지는 않는다.
Exec Shield로부터 나오는 다른 특징들로 일명 위치 독립 코드(PIE), 리눅스 커널을 위한 주소 공간 난수화 패치, 힙과 포캣 스트링 익스플로잇을 거의 불가능하게 하는 여러 glibc 내부 보안 검사, GCC Fortify 소스 그리고 GCC 스택 프로텍터 등이 있다.
구현
편집Exec Shield는 코드 세그먼트 제한을 활용하며 모든 x86 CPU들에서 동작한다. Exec Shield가 동작하는 방식 때문에 이것은 매우 가볍다; 그러나 임의적인 가상 메모리 배치를 완전히 보호할 수는 없다. 더 높은 메모리를 실행하기 위해 mprotect()를 호출하는 방식처럼 만약 CS 제한이 되면 그 제한 아래에 대해서는 보호되지 못한다. 다행히 대부분의 애플리케이션들은 이 지점에서 상당히 정상적이다; 중요한 부분인 스택은 매핑된 라이브러리의 적어도 윗 부분이 날아가서 애플리케이션에 의해 명시적으로 호출되는 것을 제외하고는 실행 불가능하게 된다.
2004년 8월부로 Exec Shield 프로젝트에서는 어느 아키텍처에서도 mprotect()를 제한함으로써 메모리 보호를 강화하지 않는다; 비록 메모리가 초기에 실행가능하지 않을 수 있지만, 추후에 실행 가능해지며 커널은 애플리케이션이 메모리 페이지를 쓰기 가능하고 실행 가능하게 마크하게 한다. 그러나 SELinux 프로젝트와 함께 페도라 코어 배포판의 표준 정책은 이 행위를 금지한다.
같이 보기
편집외부 링크
편집- Ingo Molnar's Exec Shield patch web page Archived 2016년 3월 4일 - 웨이백 머신, includes documentation in the file ANNOUNCE-exec-shield Archived 2004년 8월 5일 - 웨이백 머신
- Newsforge Feature Article
- Red Hat Magazine Feature/Project Article
- Negative security issues with ExecShield