[Past project] 악성 코드 공격의 방지를 위한 비정상적 프로그램 제어 흐름의 차단에 관한 연구 (선도 연구자 지원 사업, 한국학술진흥재단, 2003. 12∼2005. 11)

악성 코드 공격의 방지를 위한 비정상적 프로그램 제어 흐름의 차단에 관한 연구

 연구 배경

 버퍼 오버플로우 취약점으로 인한 인터넷 보안 위협

  인터넷의 급속한 발전과 인터넷 사용의 사회, 문화, 경제적 확산은 기존에는 생각하지 못했던 여러 심각한 보안상의 문제점들을 개인용 컴퓨터, 웹 서버와 같은 컴퓨터 시스템에서부터 라우터, 교환기 등 인터넷 기반 구조에 이르기까지 계속해서 발생시키고 있다. 보안상 취약점들은 일반적으로 하드웨어, 소프트웨어, 또는 프로토콜의 설계 및 구현상의 작은 오류에서 기인하며 이러한 보안상 취약점들을 이용하면 악의적인 공격자가 원격에서 네트워크의 트래픽 증가, 컴퓨터 시스템의 부하 증가, 인터넷 서비스의 마비, 더 나아가서는 임의의 명령이나 프로그램을 실행함으로써 컴퓨터 시스템의 권한을 장악하는 등 심각한 보안 위험을 야기 시킬 수 있다. 이러한 여러 취약점들 중, 가장 큰 비중을 차지하는 것이 버퍼 오버플로우 취약점 (buffer overflow vulnerability)이다 [15].
  표 1에서 나타난 바와 같이, 2002년 10월 Steve Christey가 CVE (Common Vulnerabilities and Exposures)에서 조사한 내용에 따르면, 버퍼 오버플로우 취약점은 여러 보안 취약점 중에서 발생 빈도순으로 가장 큰 비중 (21.7%)을 차지하고 있다 [1]. 뿐만 아니라, 다른 보안 취약점과는 달리, 보안 취약성을 지닌 시스템의 제어 흐름을 직접적으로 변경시켜 임의의 명령이나 프로그램을 실행시킴으로써 훨씬 더 심각한 보안상의 위협을 야기 시킬 수 있다. 2001년의 Code Red I, II, 2003년 1월의 SQL_Slammer, 또 가장 최근인 2003년 8월의 W32.Blaster 웜 (worm)에 이르기까지 최근에 나타난 대부분의 심각한 보안 위협들의 직간접적인 원인이 됨으로써, 실제 수치상으로 드러난 것보다 훨씬 더 위협적인 요소로 인식되고 있어 가장 민감한 주제로 다루어지고 있다. [8]

표 1. 보안 취약점들의 발생 빈도에 따른 분류

  버퍼 오버플로우를 사용한 대표적인 예로 2003년 1월에 발생한 SQL_Slammer (Sapphire) 웜을 들 수 있다. 이 웜은 마이크로소프트사의 SQL 서버의 취약점을 이용하여 전파되었으며, 코드레드 웜과 같이 메모리에 상주하면서 감염된 시스템으로 하여금 불특정 IP 주소로 UDP 1434 포트를 이용하여 계속적으로 웜을 복제하여 전파시킨다. 취약성을 내포한 시스템뿐만 아니라 취약성을 가지고 있지 않은 시스템에도 패킷을 보내게 됨으로써 네트워크 트래픽의 과 부화와 이로 인한 이상 현상들을 야기 시켰다. SQL_Slammer 웜의 특징적인 부분은 바로 웜의 코드 자체가 매우 간단하게 구성되어 있다는 점이다. 즉, 376 바이트의 웜은 취약점이 있는 시스템에 버퍼 오버플로우를 일으켜 외부로부터 임의의 명령어를 실행할 수 있도록 하여, 웜 코드를 불특정 IP 주소로 반복적으로 발송하는 것이다 [2, 16, 21].
  CAIDA (Cooperative Association for Internet Data Analysis)의 분석 보고서에 따르면 전 세계의 패치 되지 않은 약 10여만 대의 SQL 서버를 단 8분 만에 대부분 감염시킴으로써, 지금까지 가장 빠른 전파 속도를 가진 웜으로 기록되었다 [2]. Mi2g에 의한 보고에 따르면 SQL_Slammer 웜이 나타난 처음 5일 동안 전 세계 피해액이 9억 5천만 달러에서 최고 12억 달러에 이르는 것으로 추정하고 있다. 그 구체적인 주요 피해 현황은 아래와 같다.

  - 비상 전화 시스템 장애
  - 인터넷 기간망인 네임서버의 마비 (13개의 최 상위 네임서버들 중에서 5개까지 마비)
  - 항공권 등 온라인 예매 시스템 작동 중단
  - 은행 ATM 기기의 작동 중단 및 속도 저하
  - 신용 카드 서비스 등 지불 결제 시스템의 장애
  - 한국 및 다른 주요 국가에서 발생한 인터넷 망 마비 상태

SQL_Slammer Worm의 감염도

 버퍼 오버플로우 취약성 (Buffer Overflow Vulnerability)

  strcat, strcpy, sprintf와 같은 대부분의 C 라이브러리 루틴들은 자동적인 배열 범위 점검을 구현하지 않기 때문에 배열의 경계를 넘어 더 많은 데이터를 저장하는 것은 일반적으로 프로그래밍 에러가 아니며 그 대신에 버퍼 오버플로우라 불리는 보안 취약점을 노출시키는 결과를 초래한다. 버퍼는 한정된 양의 데이터만 저장할 수 있으므로, 버퍼를 채우고 남은 나머지 데이터들은 인접한 메모리 공간을 침범하여 그곳에 저장되어 있는 유효한 데이터를 손상시키거나 덮어쓰게 된다. 예를 들어, 인접한 메모리 공간에 놓여 있는 데이터가 프로그램의 실행 스택 (execution stack)에 놓여있는 호출 함수 (calling routine)의 리턴 주소인 경우, 리턴 주소는 악의적인 작업을 수행할 수 있는 코드의 주소로 변경되어질 수 있다. 이러한 악의적인 코드는 침입자가 의도하는 특정한 기능을 수행할 수 있는 명령어들로서 침입자에의해 버퍼 오버플로우 공격에서 버퍼를 채우고 남는 나머지 데이터의 형태로 전달된다. 이 명령어들은 사용자의 파일을 손상시키고, 데이터를 바꾸거나 중요한 정보를 노출시키는 등의 기능을 수행할 수 있다 [15, 20].

  버퍼 오버플로우는 그림 1 의 (a)에서 텍스트 영역을 제외한 나머지 세 영역, 즉 스택, 힙 (heap)과 같은 동적 데이터 세그먼트는 물론 정적 데이터 세그먼트(static data segment)에서 모두 발생 가능하나 스택 영역이 그 중 가장 공격에 취약하기 때문에 대부분은 스택에서 발생한다.

그림 1. x86 마이크로프로세서의 메모리 구조

그림 2. 버퍼 오버플로우로 인한 리턴 주소의 변경

  그림 2에서 설명하듯이 스택 영역에서 버퍼 오버플로우가 발생하면 리턴 주소는 원래의 리턴 위치가 아닌, 다른 리턴 위치를 가리키게 된다. 이와 같이 변경된 리턴 주소는 외부로부터 들어온 (스택 세그먼트 내에 위치한) 악성 코드를 가리키거나 프로그램 내부에 이미 존재하는 (텍스트 세그먼트 내에 위치한) 함수를 가리킬 수 있다.

  그림 3은 리턴 주소를 직접 변경하는 경우를 포함하여 일반 포인터 변수나 프레임 포인터를 이용하여 간접적으로 리턴 주소를 변경하는 버퍼 오버플로우 시나리오들을 설명하고 있다. 이렇게 간접적으로 리턴 주소와 같은 코드 주소를 변경하는 공격을 비선형 공격 (non-linear attack)이라 부른다.

그림 3. 발생 원인에 따른 분류

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

  버퍼 오버플로우 취약점을 막기 위해 일반적으로 사용되는 기존의 대처 방법은, 취약점이 발견된 이후에 문제가 발생한 프로그램의 소스 코드를 수정하고, 이를 다시 컴파일 하여 해당 취약점만을 해결하는 다소 불완전한 방법이라고 할 수 있다. 즉, 소스 코드에서 버퍼 오버플로우 취약점이 발견되었거나, 취약점이 발견되기 이전에 이미 버퍼 오버플로우 공격이 발생한 경우, 발견된 부분에서 더 이상 문제가 일어나지 않도록 배열 범위 검사를 해준 후에, 재 컴파일 (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) 연구의 초석이 될 것으로 기대하는 바이다.

 참고 문헌

[1] CVE, "[TECH] Vulnerability types seen in CVE", Oct. 2002, http://cve.mitre.org/board/archives/2002-10/msg00005.html
[2] CAIDA, "Analysis of the Sappire Worm", Jan. 2003,http://www.caida.org/analysis/security/sapphier/
[3] R. W. M. Jones and P. H. J. Kelly. "Backwards-compatible bounds checking for arrays and pointers in C programs", In Proceedings of the Third International Workshop on Automated Debugging, 1997.
[4] Symantec, "Blended Attacks Exploits, Vulnerabilities and Buffer-Overflow Techniques in Computer Viruses", In Virus Bulletin Conference, Sep. 2002.http://www.symantec.com
[5] Crispin Cowan, Perry Wagle, Calton Pu, Steve Beattie, and Jonathan Walpole. "Buffer Overflows: Attacks and Defenses for the Vulnerability of the Decade", In the DARPA Information Survivability Conference and Expo DISCEX, 1999.
[6] Bulba and Kil3r. "BYPASSING STACKGUARD AND STACKSHIELD", Phrack, 10(56), May, 2000http://www.phrack.org
[7] Changwoo Pyo and Gyungho Lee, "Encoding Function Pointers and Memory Arrangement Checking against Buffer Overflow Attack"
[8] S. Staniford et al., "How to own the Internet in your spare time," USENIX Security Symposium, 2002.
[9] J. Viega, J. T. Bloch, T. Kohno, and G. McGraw. "ITS4: A Static Vulnerability Scanner for C and C++ Code", In Proceedings of Annual Computer Security Applications Conference, Dec 2000.
[10] Bell Labs, Lucent Technologies, "Libsafe: Protecting Critical Elements of Stacks", Dec. 1999,http://www.bell-labs.com/org/11356/libsafe.html
[11] Solar Designer, "Non-Executable User Stack"http://www.false.com/security/linux-stack/
[12] Crispin Cowan, Steve Beattie, Ryan Finnin Day, Calton Pu, Perry Wagle, and Erik Walthinsen, "Protecting Systems from Stack Smashing Attacks with StackGuard", In the Linux Expo, 1999.
[13] Tzi-Cker Chiueh and Fu-Hau Hsu. "RAD: A Compile-Time Solution to Buffer Overflow Attacks", In 21st International Conference on Ditributed Computing Systems, 2001.
[14] David A. Wheeler, "Secure Programming for Linux HOWTO", Feb. 2000
[15] Aleph One, "Smashing the Stack for Fun and Profit.", Phrack Magazine, 7(49), Nov. 1996 http://www.phrack.org
[16] Ahnlab, "SQL_Overflow웜의 분석 보고서", Feb. 2003,http://www.ahnlab.com
[17] Crispin Cowan, Calton Pu, Dave Maier, Heather Hinton, Jonathan Walpole, Peat Bakke, Steve Beattie, Aaron Grier, Perry Wagle and Qian Zhang, "StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks", In Proceedings of the 7th USENIX Security Conference, January 1998.
[18] David Larochelle and David Evans. "Statically Detecting Likely Buffer Overflow Vulnerabilities", In 2001 USENIX Security Symposium, 2001.
[19] Kyung-suk Lhee and Steve J. Chapin, "Type-Assisted Dynamic Buffer Overflow Detection", 11th USENIX Security Symposium, 2002
[20] dark spyrit aka Barnaby Jack. "Win32 buffer overflows (Location, Exploitation and prevention)", Phrack Magazine, 15(55), Sep, 1999 http://www.phrack.org
[21] Ahnlab, "인터넷 웜과 바이러스의 진화와 전망", April. 2003, http://www.ahnlab.com.