Exec Shield for the Linux Kernel
글쓴이: xyhan / 작성시간: 일, 2003/05/04 - 2:32오후
버퍼 오버플러를 방어하는 기술 외에도..
딸린게 더 있는 것 같습니다...
exec shiel때문에..
exploit 제작이 힘들어지겠네요..
해커되기도 갈수록 힘들어 지겠어요..
IPV6도 있고..-_-
Quote:
Ingo Molnar [interview] has announced a new kernel-based security feature for Linux/x86 called "Exec Shield". He describes the patch, which is against the 2.4.20-rc1 kernel, as:
"The exec-shield feature provides protection against stack, buffer or function pointer overflows, and against other types of exploits that rely on overwriting data structures and/or putting code into those structures. The patch also makes it harder to pass in and execute the so-called 'shell-code' of exploits. The patch works transparently, ie. no application recompilation is necessary."
Ingo goes on to provide a lengthy and quite informative description of Exec Shield, beginning with a little background describing the problem that the patch works to fix. This is followed with a longer section devoted to describing how the solution has been implemented, followed by an examination of its limitations. The final section describes how the patch is installed and used. Read on for Ingo's excellent writeup, and some of the resulting discussion.
Forums:
BSD쪽 성과를 반영한 것입니까?
지난 번에 프비인가 어딘가에서 오버플로우를 방지하는 뭔가를 구축했다고 했던 게 언뜻 떠오릅니다.
그것과 관련된 것입니까?
Re: BSD쪽 성과를 반영한 것입니까?
오버플로우 방지는 openBSD 에서 gcc 에 stack protector 패치를 적용하여 패키지들을 빌드한 것을 말하는 듯 싶습니다.
그리고 Exec Shield for the Linux Kernel 는 제 생각으로는 OpenWall 프로젝트를 말하는 듯 싶습니다. 이 프로젝트의 패치를 적용하면 다음의 효과를 볼 수 있습니다.
실행불가능한 사용자 스택공간
/tmp 에서의 링크 제한
/tmp 에서의 FIFOs 제한
/proc 제한
fd 0 과 1,2 에 대한 특별 설정
execve 에서의 RLIMIT_NPROC 강화
파괴된 공유 메모리 세그먼트를 사용하지 않음
(이상 Securing & Optimizing Linux; The Ultimate Solution 에서 인용)
http://www.openwall.com 을 참고 하시면 되겠습니다.
제 개인적인 판단으로는.. 둘 다 장단점이 있습니다.
openwall 의 패치의 경우 커널에서 제어를 해 주기 때문에 커널만 패치하여 새로 빌드하는 것으로 모든 작업이 간단하게 됩니다. 하지만 커널 빌드에 신속하게 패치가 나오지는 못한다는 점 (새로운 커널이 나오면 즉시즉시 빌드 하시는 분들께는 아주 민감하죠 ^^)
과 다른 응용 프로그램과의 관계가 어떻게 될 지 예측을 할 수 없다는 부분입니다.
반면에 stact protect 패치를 이용한다면, 일단 gcc 와 glibc 에 stack protect 패치를 적용하여 설치한 다음 다른 모든 패키지들을 다시 빌드해 줘야 한다는 단점이 있습니다. 또한, gcc 에서 libc 를 불러 들이지 않는 옵션을 주었을 경우에는 __guard 와 __stack_smash_handler 를 직접 정의해 주어야 한다는 단점이 있습니다. 물론 libc 를 호출할 일이 없는 패키지라면 stack protection 이 적용되지 않는 gcc 에서 빌드된 것으로 설치를 해도 무방합니다만.. ^^; 일단 perl 은 stack protector 패치가 된 gcc 에서는 빌드가 되지를 않더군요.
일단 저의 경우에는 stack protection 을 선택한 입장입니다만 openwall 의 패치가 만약 정식으로 linux kernel 에 들어오게 될 경우라면 전환을 고려해 볼 수도 있을 것 같습니다.