My Study/Exploit2010.04.29 21:05
비록 옛날 글이지만 이렇게 방어를 하고 있다는 내용과 방어기법에 대한 문제점에 대해 작성된 글입니다.

 기존 연구: 버퍼 오버플로우 취약점에 대한 기존의 대처 방안들

  버퍼 오버플로우 취약점을 막기 위해 일반적으로 사용되는 기존의 대처 방법은, 취약점이 발견된 이후에 문제가 발생한 프로그램의 소스 코드를 수정하고, 이를 다시 컴파일 하여 해당 취약점만을 해결하는 다소 불완전한 방법이라고 할 수 있다. 즉, 소스 코드에서 버퍼 오버플로우 취약점이 발견되었거나, 취약점이 발견되기 이전에 이미 버퍼 오버플로우 공격이 발생한 경우, 발견된 부분에서 더 이상 문제가 일어나지 않도록 배열 범위 검사를 해준 후에, 재 컴파일 (re-compilation) 을 한 후, 기존의 취약점이 발견된 파일을 새로 생성된 파일로 대체하는 것이다. 이는 이메일 또는 네트워크 다운로드 형태로 해당 소프트웨어 제공업체의 웹 사이트로부터 보안 패치 (patch)가 전송되어 진행되며 마이크로소프트 Windows, Linux를 비롯한 대부분의 상용 운영 체제나 웹 서버 등의 응용 소프트웨어들이 버퍼 오버플로우 취약점에 대응하기 위해 실제로 흔히 사용되는 방법이다. 따라서, 새로이 발견된 취약점들에 대해서만 방어가 가능하다는 단점을 갖고 있으며 아직 발견되지 않은 버퍼 오버플로우 취약점을 미리 예측하고 막아내는 것은 어렵다고 할 수 있다.

  아직 발견되지 않은 버퍼 오버플로우 취약점을 사전에 방지하기 위한 기존의 연구 방안은 아래와 같다.

명령어 실행이 불가능한 버퍼 (non-executable buffer)
  버퍼 오버플로우를 방지하기 위한 운영체제 수준의 방어 전략이라고 할 수 있다. 운영체제가 관리하는 페이지들 중, 데이터 영역에 할당된 페이지들에 대해 실행 권한을 주지 않음으로써 데이터 영역에서의 명령어의 실행을 원천적으로 봉쇄하는 방법이다. 따라서, 버퍼 오버플로우 공격으로 탑재된 악성 코드의 경우, 데이터 영역에만 복사될 수 있기 때문에 이러한 악성 코드의 실행은 원천적으로 봉쇄된다. 하지만, 리눅스 에서 signal 및 gcc “trampolines” 를 구현하는 경우에는 정상적인 실행 도중 스택 영역의 명령어를 실행해야 하는 경우가 존재하므로, 단순히 데이터 영역의 실행 권한만 제한하는 방법으로는 이러한 프로그램들을 제대로 실행하기가 어렵게 된다. 또한 데이터 영역에서 직접 명령어를 실행하지 않더라도, 변경된 리턴 주소가 기존 프로그램 텍스트 영역 내의 특정 코드를 가리키게 하여 원하는 기능을 수행할 수도 있으므로, 이러한 방법으로는 버퍼 오버플로우를 제대로 막기가 어렵다 [11].

정적 검사와 배열 범위 검사 (static analysis and array bound checking)
  버퍼 오버플로우를 방지하기 위한 컴파일러 수준의 방어 전략으로 배열 범위 검사를 들 수 있다. 컴파일 시, 배열에 대한 모든 읽기, 쓰기가 배열의 범위를 벗어나지 않는지 검사하는 명령어를 삽입한다. 이러한 방법은 배열 변수를 통한 버퍼 오버플로우를 완벽하게 해결할 수 있지만, 실행 시간 면에서 지나친 성능 저하를 가져오며 포인터 (pointer) 변수와 같이 범위가 정해져 있지 않은 변수를 통한 버퍼 오버플로우 공격에는 사용하기가 어렵다. 또한, 기존에 이미 설치된 운영체제나 상용 소프트웨어의 경우, 재 컴파일이 불가능하여 실제로 사용되는 경우가 거의 없다. 대신에 배열 범위 검사에 사용되는 정수 범위 검사 (integer range analysis)와 취약점 함수 스캐닝 (scanning for functions known to be vulnerable)과 같은 정적 컴파일러 분석 기술 (static compiler analysis technique)들이 취약점을 발견하기위해 일반적으로 사용되어지며 발견된 취약점은 자동 또는 수동으로 패치 되어 진다 [3, 9, 14, 18, 19].

안전한 라이브러리 (Libsafe)
  동적 라이브러리를 이용해 구현되며, 별도의 라이브러리를 이용해 구현되므로 기존의 라이브러리를 재 컴파일 할 필요가 없다. 취약한 함수가 수행되려 할 때 함수의 실행을 가로채서 그 함수를 실행시키는 대신, 그것을 대체할 수 있는 안전한 함수를 대신 실행시킨다. 또한, 이러한 취약한 함수에 대한 대처 뿐 아니라, 리턴 주소에 대한 검사도 기존의 소스 코드에 대한 재 컴파일 없이 수행이 가능하다 [10].p>

스택 가드 (StackGuard)와 포인트 가드 (PointGuard)
  버퍼 오버플로우를 방지하기 위한 또 하나의 컴파일러 방어 전략이라고 할 수 있다. 컴파일 타임에 리턴 주소의 변경을 방지하기 위해, 리턴 주소 바로 앞에 특정한 값 (Canary)을 삽입하여, 이 값의 변경 여부를 이용해 버퍼 오버플로우의 발생을 알아내는 방법이다. 그러나 리턴 주소 이외의 값을 사용하는 버퍼 오버플로우 취약점에 대해서는 방어가 어렵다는 단점이 있다. 포인트 가드 (PointGuard)는 스택 가드 전략을 확장한 방법으로서 스택 가드가 리턴 주소의 변경만을 검사하는 것에 반해, 리턴 주소뿐 아니라 다른 어떠한 값들에 대해서도 스택 가드와 동일한 방법으로 값의 변경을 막을 수가 있다. 하지만 실행 시간 면에서 지나친 성능 저하를 가져오며 배열 범위 검사와 같이 재 컴파일이 실제 이용되기 어려운 점 때문에 사용되는 경우는 거의 없다 [5, 12, 14, 17].

리턴 주소 방어 기술 (Return Address Defender)
  버퍼 오버플로우를 막기 위한 컴파일러 수준의 전략 중 하나로서, 컴파일을 수행할 때 버퍼 오버플로우를 방지하기 위한 명령어들이 기존의 코드에 추가된다. 함수가 시작될 때에는 리턴 주소를 데이터 세그먼트의 특정한 위치에 저장해 놓고, 함수가 리턴 될 때에는 스택 포인터가 가리키는 리턴 주소를 함수 시작 시 저장해놓은 해당 리턴 주소와 비교해 오버플로우 발생 여부를 판단할 수 있다. 하지만 여러 종류의 버퍼 오버플로우 중 리턴 주소를 이용하는 스택 오버플로우에 한해서만 방어가 가능하다 [13].

프로그램 카운터와 함수 주소 암호화 (PC or Function Pointer Encoding)  버퍼 오버플로우에 대처할 수 있는 전략 중 하나로서 컴파일러 수준 또는 하드웨어 수준에서 구현될 수 있다. 함수가 시작될 때, 리턴 주소를 스택 포인터와 XOR하여 인코딩 한 후에 스택 프레임에 저장을 하고, 함수가 리턴 될 때 저장된 리턴 주소를 다시 스택 포인터와 XOR하여 디코딩 해 사용하게 된다. 따라서 변경된 리턴 주소는 디코딩 시에 침입자의 의도와는 다른 임의의 주소를 가리키게 되며 따라서 공격받은 프로그램의 실행은 궁극적으로 중단하게 된다. 이 아이디어를 확장하여 함수 포인터에 대한 암호화/복호화 방안도 제시되었다 [7].

 본 연구의 목적 및 방향

 기존 대처 방안의 문제점

  인간의 개입이 요구되는 보안 공격 대응 기법은 앞으로의 속도전 적인 웜 공격에는 무기력하다. - “속도전”的인 웜 epidemic의 양상은 SQL_Slammer 웜에 국한된 것이 아니며, 앞으로는 더욱 심각해질 전망이다. 특히 현재의 네트워킹 기술을 감안하였을 때 전 세계적 웜 전파의 이론적인 최소 시간은 약 10여초에 불과할 수 있다 [8]. 이는 네트워크 운영자의 현실적인 반응 시간을 고려할 때, 앞으로는 전통적인 방법, 즉 보안 패치의 다운로드나 재 컴파일과 같은 인간의 개입이 요구되는 대응 기법이 무력할 것임을 암시한다. 따라서 앞으로 다가올 보안 위협들에 효과적으로 대응하기 위해선 사전 방어 전략 또는 실시간 (real-time) 공격 탐지와 대응을 자동적으로 가능케 하는, 보다 근본적이고 효율적인 대응 체계가 갖춰져야 할 것이다.

  발견된 취약점만을 해결하는 임시방편적인 해결책 보다는 발견되지 않은 취약점을 이용한 알려지지 않은 새로운 웜 (unknown worms) 공격에 대한 방어 기술이 요구된다. - 기존의 인터넷 공격의 대처 방안은 취약점이 발견된 이후에 문제가 발생한 프로그램의 소스 코드를 수정하고, 이를 다시 컴파일 하여 해당 취약점만을 해결하는 방법으로 알려진 취약점이나 웜에 대하여는 대처가 가능하나 알려지지 않은 웜 또는 알려지지 않은 취약점에 대해서는 무기력하다.

  이론적 연구 보다는 실제 구현되어 실생활에 적용될 수 있는 버퍼 오버플로우 취약점 해결 방안이 요구된다. - 배열 범위 검사를 통한 버퍼 오버플로우 취약점의 제거, 또는 Canary를 이용한 버퍼 오버플로우 취약점의 탐지와 같은 컴파일러 기술은 기존의 상용 소프트웨어에는 적용이 불가능하며 모든 다양한 운영체제, 다양한 프로세서 상에서의 모든 상용 컴파일러에 적용하지 않는 이상, 그 실제 사용은 거의 제한적일 수밖에 없다. 또한 이를 통한 성능 저하는 이러한 컴파일러 기술의 보급을 제한하는 또 하나의 문제점이다.

 본 연구의 목적

  본 연구에서는 버퍼 오버플로우 취약점을 이용, 악성 코드를 실행시키는 최근의 웜 기반 보안 공격을 원천적으로 막기 위하여 기존의 소프트웨어 수준에서의 보안 패치 또는 재 컴파일 (Recompile)을 통한 소프트웨어 기반에서 처리하는 방법들과는 달리, 하드웨어 수준, 즉 프로세서 내부적으로 이러한 악성 코드의 실행을 탐지함으로써 기존의 알려진 웜 공격뿐만 아니라 알려져 있지 않은 새로운 웜 공격을 원천적으로 방지하는 기술을 연구하는 것을 목적으로 한다.

 연구 방향

  버퍼 오버플로우 취약점을 이용한 최근의 인터넷 공격 양상은 악성 코드의 실행을 목표로 하고 있다. 이와 같은 악성 코드의 실행은 정상적인 프로그램의 제어 흐름을 바꿈으로써 시작된다. 이는 간접 분기 명령 시 이용되는 명령어의 주소를 바꾸는 방법을 사용하며, 그 중에서도 가장 흔하게 사용되는 방법이 스택 프레임에 저장되어 있는 리턴 주소의 변경을 통한 악성 코드의 실행이다. 이러한 웜 공격의 일반적인 특징은 버퍼 오버플로우의 취약성을 이용하여 리턴 주소 (return address)나 함수 주소 (function pointer)처럼 분기 명령의 목표 주소 (target address)를 비정상적으로 변경시킴으로써 제어 흐름을 바꿈으로써 시작된다. 따라서 이러한 불법적인 프로그램 제어 흐름을 프로세서 내부에서 원천적으로 탐지하는 것이 본 연구가 개발하려하는 핵심 기술이다.

  이러한 프로세서 구조적 차원의 악성 코드 실행의 탐지 및 방지 기술은 다음과 같은 장점을 갖고 있다.

  기존의 대처 방법은, 취약점이 발견된 이후에 문제가 발생한 프로그램의 소스 코드를 수정하고, 이를 다시 컴파일 하여 해당 취약점만을 해결하는 다소 불완전한 방법으로 인간의 개입이 요구되어 SQL_Slammer와 같은 빠른 전파 속도를 가진 웜에는 무기력하다. 반면에 프로세서 내부에서의 비정상적 프로그램 실행의 탐지는 인간의 개입이 필요 없는 실시간 탐지 기술로 네트워크/컴퓨터 보안 솔루션을 뚫고 들어온 웜 공격을 프로세서 내부에서 최종적으로 실시간에 차단시킴으로써 전파 속도에 관계없이 웜의 전파를 사전에 탐지 방어할 수 있는 기술이다.

  기존의 대처 방법은 알려진 웜이나 바이러스에는 패치 또는 솔루션 제공이 가능하나 알려져 있지 않은 새로운 웜의 공격에는 무기력한 사후 대처 방법이 대부분이다. 반면에 본 연구에서 개발할 프로세서 내부에서의 악성 코드 실행의 탐지 및 제거 기술은 알려진 취약점을 통한 공격은 물론 알려져 있지 않은 취약점을 이용한 웜의 공격 역시 원천적으로 방어할 수 있는 새로운 개념의 악성 코드 퇴치 기술이다.

  이제 보안의 이슈는 더 이상 프로세서 외부적인 문제만은 아니다. 방화벽 (Firewall), 침입탐지 시스템 (Intrusion Detection System), 애티바이러스 (Anti-Virus Software)와 같은 기존의 보안 관련 시스템 및 소프트웨어와 함께 안전한 운영 체제 기술 (Secure Operating System), 안전한 프로그램 생성을 위한 컴파일러 기술 등 보안 이슈는 컴퓨터 분야 전 분야에 걸쳐 새로운 방향을 제시하고 있다. 본 연구는 그 동안 컴퓨터 성능 향상에만 매달려 있는 컴퓨터 구조 연구를 프로세서 내부적으로 침입을 탐지하여 궁극적으로 보안 공격으로부터 실행중인 소프트웨어를 보호할 수 있는 안전한 프로세서의 설계 방향을 제시함으로써 안전한 프로세서 구조 (Secure Processor Architecture) 연구의 초석이 될 것으로 기대하는 바이다.

출처 : 한국학술진흥재단
사이트 : http://it.korea.ac.kr/research/project/secure.html
Posted by Ezbeat