이그제큐티브 실드
Exec ShieldExec Shield는 2002년 말 Red Hat, Inc.에서 시작된 프로젝트로 Linux 시스템에 대한 웜 또는 기타 자동 리모트 공격의 위험을 줄이는 것을 목적으로 합니다.이 프로젝트의 첫 번째 결과는 하드웨어에 네이티브 NX 구현이 없는 x86 CPU의 NX 비트를 에뮬레이트하는 Linux 커널용 보안 패치입니다.Exec Shield 프로젝트에는 다른 구성 요소가 많이 있지만 일부에서는 이 첫 번째 패치를 Exec Shield라고 합니다.
첫 번째 Exec Shield 패치는 데이터 메모리를 실행 불가능으로, 프로그램 메모리를 쓰기 불가능으로 플래그 지정하려고 합니다.이를 통해 버퍼 오버플로우 및 데이터를 덮어쓰고 이러한 구조에 코드를 삽입하는 데 의존하는 다른 기술에서 발생하는 보안 공격과 같은 많은 보안 공격이 억제됩니다.또한 Exec Shield는 mmap() 및 힙베이스의 주소 공간 레이아웃 랜덤화를 제공합니다.
이 패치는 셸 코드 삽입 및 실행의 어려움을 가중시켜 대부분의 부정 이용을 무효로 합니다.일부 애플리케이션(Mono, Wine, XEmac, Mplayer)은 완전히 호환되지 않지만 exec-shield를 완전히 활용하기 위해 애플리케이션을 재컴파일할 필요는 없습니다.
Exec Shield 프로젝트에서 나온 다른 기능으로는 PIE(Position Independent Executables), Linux 커널용 주소 공간 랜덤화 패치, 힙 및 포맷 문자열 부정 이용을 거의 불가능하게 만드는 광범위한 glibc 내부 보안 검사 세트, GCC Fortify 소스 기능 및 GCC 스택 보호 기능 등이 있습니다.ature.
실행
Exec Shield는 코드 세그먼트 제한을 사용하는 모든 x86 CPU에서 작동합니다.Exec Shield는 작동 방식 때문에 매우 가볍지만 임의 가상 메모리 레이아웃을 완전히 보호하지는 않습니다.예를 들어 메모리 용량을 늘리기 위해 mprotect()를 호출하는 등 CS 제한을 높이면 보호는 이 제한보다 낮아집니다.Ingo Molnar는 이메일 대화에서 이것을 지적한다.대부분의 애플리케이션은 이 점에 있어서 매우 정상입니다.스택(중요한 부분)은 적어도 맵된 라이브러리 위에 있기 때문에 어플리케이션의 명시적인 호출에 의한 경우를 제외하고 실행 가능한 파일이 되지 않습니다.
2004년 8월 현재 Exec Shield 프로젝트에서는 어떤 아키텍처에서도 mprotect()를 제한함으로써 메모리 보호를 시행하는 것은 없습니다.메모리는 처음에는 실행 불가능할 수 있지만 나중에 실행 가능해질 수 있기 때문에 커널에서는 메모리 페이지를 쓰기 가능과 실행 가능으로 동시에 마킹할 수 있습니다.단, Security-Enhanced Linux 프로젝트(SELinux)와 연계하여 Fedora Core 배포의 표준 정책에서는 호환성을 이유로 일부 예외만 제외하고 대부분의 실행 파일에 대해 이 동작을 금지하고 있습니다.
역사
Exec Shield는 Red Hat의 다양한 사람들에 의해 개발되었습니다.첫 번째 패치는 Red Hat의 Ingo Molnar에 의해 출시되었으며 2003년 5월에 처음 출시되었습니다.버전 [1][2]3 이후 Fedora Core 1~6 및 Red Hat Enterprise Linux의 일부입니다.다른 관련자들로는 야쿠브 젤리넥, 울리히 드레퍼, 리처드 헨더슨, 아르얀 반 데 벤 등이 있다.
「 」를 참조해 주세요.
레퍼런스
- ^ "Fedora Core 1 Release Notes". Red Hat, Inc. November 2003. Archived from the original on 2003-12-02. Retrieved 2007-10-18.
- ^ van de Ven, Arjan (August 2004). "New Security Enhancements in Red Hat Enterprise Linux v.3, update 3" (PDF). Red Hat, Inc. Archived from the original (PDF) on 2005-05-12. Retrieved 2007-10-18.
