소프트웨어 공격이 성공하기 위해서는 공격 코드가 프로그램의 주소 공간에 주입된 후 프로그램의 제어 흐름이 공격 코드 위치로 변경되어야 한다. 프로그램의 주소 공간 중 코드 영역은 실행 중에 변경이 불가능하므로 공격 코드가 주입될 수 있는 곳은 데이터 영역 밖에 없다. 따라서 데이터 영역으로 프로그램의 제어가 변경될 경우 주입된 공격 코드로 제어가 옮겨 가는 공격이 발생한 것으로 판단할 수 있다. 따라서 본 논문에서는 프로그램의 제어 흐름과 관련된 CALL, JMP, RET 명령어의 목적 주소를 검사하여 제어가 옮겨갈 목적 주소가 프로그램의 실행 코드가 저장된 텍스트 영역이 아닌 데이터 영역일 경우 소프트웨어 공격이 발생한 것으로 간주하는 소프트웨어 공격 탐지 기법을 제안하였다. 제안된 방법을 이용하면 함수의 복귀주소뿐만 아니라 함수포인터, longjmp() 버퍼 등 프로그램 제어 흐름과 관련된 모든 데이터가 변경되었는지 점검할 수 있었기 때문에 기존 기법들보다 더 많은 종류의 공격을 탐지할 수 있었다.
소프트웨어 공격이 성공하기 위해서는 공격 코드가 프로그램의 주소 공간에 주입된 후 프로그램의 제어 흐름이 공격 코드 위치로 변경되어야 한다. 프로그램의 주소 공간 중 코드 영역은 실행 중에 변경이 불가능하므로 공격 코드가 주입될 수 있는 곳은 데이터 영역 밖에 없다. 따라서 데이터 영역으로 프로그램의 제어가 변경될 경우 주입된 공격 코드로 제어가 옮겨 가는 공격이 발생한 것으로 판단할 수 있다. 따라서 본 논문에서는 프로그램의 제어 흐름과 관련된 CALL, JMP, RET 명령어의 목적 주소를 검사하여 제어가 옮겨갈 목적 주소가 프로그램의 실행 코드가 저장된 텍스트 영역이 아닌 데이터 영역일 경우 소프트웨어 공격이 발생한 것으로 간주하는 소프트웨어 공격 탐지 기법을 제안하였다. 제안된 방법을 이용하면 함수의 복귀주소뿐만 아니라 함수포인터, longjmp() 버퍼 등 프로그램 제어 흐름과 관련된 모든 데이터가 변경되었는지 점검할 수 있었기 때문에 기존 기법들보다 더 많은 종류의 공격을 탐지할 수 있었다.
Successful software attacks require both injecting malicious code into a program's address space and altering the program's flow control to the injected code. Code section can not be changed at program's runtime, so malicious code must be injected into data section. Detoured flow control into data s...
Successful software attacks require both injecting malicious code into a program's address space and altering the program's flow control to the injected code. Code section can not be changed at program's runtime, so malicious code must be injected into data section. Detoured flow control into data section is a signal of software attack. We propose a new software attack detection method which verify the target address of CALL, JMP, RET instructions, which alter program's flow control, and detect a software attack when the address is not in code section. Proposed method can detect all change of flow control related data, not only program's return address but also function pointer, buffer of longjmp() function and old base pointer, so it can detect the more attacks.
Successful software attacks require both injecting malicious code into a program's address space and altering the program's flow control to the injected code. Code section can not be changed at program's runtime, so malicious code must be injected into data section. Detoured flow control into data section is a signal of software attack. We propose a new software attack detection method which verify the target address of CALL, JMP, RET instructions, which alter program's flow control, and detect a software attack when the address is not in code section. Proposed method can detect all change of flow control related data, not only program's return address but also function pointer, buffer of longjmp() function and old base pointer, so it can detect the more attacks.
* AI 자동 식별 결과로 적합하지 않은 문장이 있을 수 있으니, 이용에 유의하시기 바랍니다.
문제 정의
한다. 본 논문에서는 이러한 특성을 이용하여 프로그램의 제어 흐름을 변경시키는 명령어들의 목적 주소가 프로그램 코드 영역인지 공격코드가 주입되어 있을 수 있는 데이터 영역인지 확인하는 소프트웨어 공격 탐지 기법을 제안하고 제안된 기법의 성능을 분석하였다.
본 논문은 Linux 운영체제에서 프로그램의 실행 흐름을 비정상적으로 변경시키는 것을 탐지함으로써 버퍼오버플로우 공격뿐만 아니라 새로운 공격 기법에 대해서도 대응이 가능한 새로운 소프트웨어 공격 탐지 기법을 제안한다.
가설 설정
동적 기법은 프로그램 작성 과정에서 모든 소프트웨어 취약점을 제거하는 것이 불가능하다는 가정을 바탕으로 한다. 이 기법에서는 프로그램이 실행되는 도중에 미리 알려진 소프트웨어 공격과 동일한 상태가 되면 공격으로 판단하여 프로그램의 실행을 종료하는 코드를 실행 프로그램에 포함시킨다.
제안 방법
변경되는 main。, dlopenO, dlcloseO 함수 호출을 찾아서 실행코드 영역의 범위를 획득하는 코드를 추가하였다.
RET 명령에 대해서는, 스택에 저장된 복귀주소가 text영역에 속하는지 점검하는 코드를 추가하였다. longjmpO 함수 호출의 경우에는 함수의 struct jmp_buf 타입 파라미터인 첫 번째 파라미터에서 IP가 저장된 곳의 값을 점검하는 코드를 추가하였다.
두 번째로, 첫 번째 사용된 함수를 함수포인터를 이용하여 간접주소지정 CALL 명령이 실행될 때 발생하는 오버헤드를 측정하였다. 이 경우 161.
오퍼랜드일 경우 오퍼랜드 앞에 '*' 문자를 추가한다. 따라서 CALL, JMP 명령의 오퍼랜드가 '*'로 시작될 경우 해당 명령 앞에 오퍼랜드의 값이 실행코드 영역에 속하는 지 점검하는 코드를 추가하였다. (그림 4)는 간접주소지정 CALL 명령에 대해서 현재 단계까지 처리된 결과의 예이다.
<표 2>와 같이 retum-toTibc 공격이 발생하면 실행 제어 명령어가 실행될 때 프로그램이 원래 의도하지 않았던 비정상적인 제어 흐름이 발생하지만 실행 제어 명령어의 목적 주소가 프로그램의 코드 영역에 속해 있으므로 본 논문에서 제안한 방법으로는 탐지가 불가능하다. 또한 Lisp나 Object C 등과 같은 언어는 프로그램을 수행하는 중에 스택 영역의 일부에 실행 코드를 동적으로 생성하여 실행시키는 트램폴린(trampoline) 함수 기능을 지원하는 더], 제안된 기법이 적용된 프로그램에서 트램폴린함수를 호출할 경우 정상적인 제어 흐름이지만 실행 제어명령어의 목적 주소가 프로그램의 데이터 영역에 속해 있으므로 공격으로 탐지한다. 이러한 탐지 오류는 윈도우 XP SP2의 실행보호(NX) 기법에서도 동일하게 발생한다[14].
longjmpO 함수 호출의 경우에는 함수의 struct jmp_buf 타입 파라미터인 첫 번째 파라미터에서 IP가 저장된 곳의 값을 점검하는 코드를 추가하였다. 또한 프로세스가 실행되는 동안 프로세스 메모리 영역 중 text 영역의 주소 범위를 구하기 위해서 main() 함수의 시작될 때, 그리고 dlopenO과 dlcloseO 함수가 각각 호출된 직후에 프로세스 id를 이용하여 /proc 파일시스템의 프로세스 메모리 맵으로부터 text 영역의 범위를 획득하는 코드를 호출하는 코드를 추가하였다.
먼저, RET 명령어의 오버헤드를 계산하기 위해서 아무런 작업을 수행하지 않는 함수를 500, 000, 000번 호출할 때 소요된 시간을 비교하였다. 그 결과 <표 3>에서 보인 것과 같이 113.
본 논문에서 제안한 방법을 적용했을 때 발생하는 최대오버헤드를 계산하기 위해서 RET, 간접주소지정 CALL, 간접주소지정 JMP 명령 위주로 작성된 프로그램의 실행시간을 제안된 방법이 적용되지 않았을 때의 실행시간과 비교하였다. 또한, 일반적인 경우의 오버헤드를 계산하기 위해서 함수 호출이 많은 경우인 재귀 함수를 이용해 구현된 Hanoi Tower 프로그램과 디스크 I/O 및 연산이 많은 경우인 /bin/ tar 프로그램의 실행시간을 비교하였다.
세 번째로, 두 번째 사용된 프로그램에서 호출되는 함수에 간접주소지정 JMP 명령이 포함되도록 수정한 후 오버헤드를 계산하였다. 이 경우 180.
평가를 수행하였다. 정성적 평가에서는 제안된 기법을 이용하여 발생 가능한 모든 소프트웨어 공격을 탐지할 수 있는지 확인하고, 정량적 평가에서는 제안된 기법이 어느 정도의 실행 성능 감소를 초래하는지 확인하였다.
정성적인 평가를 위해서 공개된 공격코드들에 제안된 기법을 직접 적용해보는 대신 John Willander[기가 제안한 동적 소프트웨어 공격 탐지 기법의 효과를 시험하는 테스트베드를 이용하였다. [기에서 제안한 테스트베드는 소프트웨어 공격의 공격 대상(함수포인터, 함수 복귀주소, 호출 함수의 프레임에 대한 포인터, longjmpO 버퍼)과 공격 대상이 존재할 수 있는 위치 (stack, heap, (un)initialized data) 그리고 공격 대상을 변경하는 기법(버퍼오버플로우처럼 주위 데이터를 함께 변경시키는 방법, 공격 대상 데이터만 변경하는 방법)에 따라 조합 가능한 20가지 공격 유형에 대해서 동적인 소프트웨어 공격 탐지 기법의 효과를 검증할 수 있는 도구이다(제시된 공격 유형 중 중복되는 것이 있어 18가지 공격 유형에 대해서 공격 탐지 기법의 효과를 검증할 수 있다).
제안된 기법의 성능을 평가하기 위해서 정성적 평가와 정량적 평가를 수행하였다. 정성적 평가에서는 제안된 기법을 이용하여 발생 가능한 모든 소프트웨어 공격을 탐지할 수 있는지 확인하고, 정량적 평가에서는 제안된 기법이 어느 정도의 실행 성능 감소를 초래하는지 확인하였다.
첫 번째로 C 언어 소스코드를 -S 옵션으로 컴파일하여 어셈블리 코드를 임시 파일로 생성하였다.
구현되었다[9]. 컴파일러를 직접 수정할 경우 컴파일러 버전이 변경될 경우 새로운 패치를 생성해야 하는 단점이 있으므로 본 논문에서는 공격 탐지 기법을 StackShield와 같이 gcc 드라이버 형태로 구현하였다. 구현된 gcc 드라이버가 C 언어 소스코드를 이용하여 제안된 공격 탐지 기법이 적용된 실행파일을 생성하는 과정을 (그림 3)에 나타내었다.
데이터처리
또한, 일반적인 경우의 오버헤드를 계산하기 위해서 함수 호출이 많은 경우인 재귀 함수를 이용해 구현된 Hanoi Tower 프로그램과 디스크 I/O 및 연산이 많은 경우인 /bin/ tar 프로그램의 실행시간을 비교하였다. 실행시간 계산은 Intel Pentium HI 1GHz CPU, 128MB RAM 상에서 Red Hat Linux 8.
이론/모형
이 테스트베드를 이용하여 본 논문에서 제안한 방법과 대표적 동적 소프트웨어 공격 탐지 기법인 StackGuard, StackShield, SSP의 공격 탐지 범위를 비교하면 과 같다(StackGuard, ShtackShield, SSP에 대한 평가는 [1 기의 결과를 활용하였다).
성능/효과
이용하였다. [기에서 제안한 테스트베드는 소프트웨어 공격의 공격 대상(함수포인터, 함수 복귀주소, 호출 함수의 프레임에 대한 포인터, longjmpO 버퍼)과 공격 대상이 존재할 수 있는 위치 (stack, heap, (un)initialized data) 그리고 공격 대상을 변경하는 기법(버퍼오버플로우처럼 주위 데이터를 함께 변경시키는 방법, 공격 대상 데이터만 변경하는 방법)에 따라 조합 가능한 20가지 공격 유형에 대해서 동적인 소프트웨어 공격 탐지 기법의 효과를 검증할 수 있는 도구이다(제시된 공격 유형 중 중복되는 것이 있어 18가지 공격 유형에 대해서 공격 탐지 기법의 효과를 검증할 수 있다). 이 테스트베드는 이론적으로 발생가능한 모든 소프트웨어 공격에 대해서 공격 탐지 기법이 탐지가 가능한 지를 간단하게 확인할 수 있게 해준다.
활용하였다). 결과에서 제시된 것처럼 본 논문에서 제안한 방법은 가장 많은 형태의 공격을 탐지할 수 있었다.
네 번째로, 32 개의 디스크로 이루어진 Hanoi Tower 문제의 경우 46.8%의 오버헤드가 발생했다. Hanoi Tower 문제를 재귀 함수를 이용하여 구현하면 거의 대부분의 실행시간이 함수를 호출하고 복귀하는데 소요되므로 이 오버헤드를 함수 호출이 많은 프로그램의 오버헤드로 간주할 수 있다.
윈도우 XP SP2에서는 이 두 가지 오류 중 트램폴린 함수와 관련된 문제를 해결하는 방법으로 프로그램이 동적으로 코드를 생성하여 실행시키고자 할 때는 코드를 저장할 공간을 동적으로 할당받은 후 할당된 메모리 영역에 실행가능 특성을 추가하여 사용하라고 권고하고 있다. 본 논문에서 제안한 방법도 이러한 방법을 이용하는 프로그램에 대해서는 메모리 영역의 특성을 변경하는 함수 다음에 정상적인 실행 코드 영역의 범위를 다시 계산하는 코드를 삽입함으로써 정상적인 호출을 공격으로 탐지하는 오류를 제거할 수 있다. 하지만 retum-to-libc 공격을 탐지하기 위해서는 새로운 방법을 강구해야 한다.
단점이 있다.<표 2>와 같이 retum-toTibc 공격이 발생하면 실행 제어 명령어가 실행될 때 프로그램이 원래 의도하지 않았던 비정상적인 제어 흐름이 발생하지만 실행 제어 명령어의 목적 주소가 프로그램의 코드 영역에 속해 있으므로 본 논문에서 제안한 방법으로는 탐지가 불가능하다. 또한 Lisp나 Object C 등과 같은 언어는 프로그램을 수행하는 중에 스택 영역의 일부에 실행 코드를 동적으로 생성하여 실행시키는 트램폴린(trampoline) 함수 기능을 지원하는 더], 제안된 기법이 적용된 프로그램에서 트램폴린함수를 호출할 경우 정상적인 제어 흐름이지만 실행 제어명령어의 목적 주소가 프로그램의 데이터 영역에 속해 있으므로 공격으로 탐지한다.
이 결과들로부터 제안된 방법이 일반적인 프로그램에 적용되었을 경우 프로그램의 종류에 따라 발생하는 오버헤드에 편차가 있지만 50% 이하인 것으로 추정할 수 있다.
트램폴린 함수와 관련된 문제점은 트램폴린 함수를 사용하는 프로그램을 재작성함으로써 해결할 수 있으나 retum-to-Hbc 공격의 경우 공격을 탐지할 수 있는 다른 방법을 강구하여야 한다. 정량적인 평가 결과, 제안된 방법은 일반적인 프로그램의 경우 최대 50%의 오버헤드가 발생할 수 있다는 것을 알 수 있었다. 이러한 오버헤드는 간접주소지정 JMP, 간접주소지정 CALL 및 RET 명령이 실행될 때 제어가 옮겨가는 목적지 주소가 코드 영역인지 확인하기 때문에 발생한다.
정성적인 평가 결과로부터 제안된 방법을 적용하면 소프트웨어 공격의 대상이 될 수 있는 프로그램의 제어 흐름과 관련된 18가지 종류의 데이터를 변경하는 공격 기법을 탐지할 수 있어 기존의 방법들보다 더 많은 범위의 공격을 탐지할 수 있음을 알 수 있었다. 특히 기존 방법들이 해결할 수 없었던 longjmpO와 관련된 공격을 탐지할 수 있었다.
StackGuard[8]는 함수가 호출될 때 스택에 저장되는 함수의 복귀 주소가 변경 되었는지 조사하여 공격을 탐지하는 기법이다. 즉, 지역 변수와 함수의 복귀주소 사이에 카나리아(canary)라는 임의의 값을 저장하여 두고 지역변수에서 버퍼오버플로우가 발생하여 함수의 복귀주소가 변경되면 카나리아값도 함께 변경되므로 함수에서 복귀할 때 카나리아값이 원래 값과 다른 값으로 변경되었으면 공격이 발생할 것으로 판단한다.
특히 기존 방법들이 해결할 수 없었던 longjmpO와 관련된 공격을 탐지할 수 있었다. 하지만 제안된 방법은 실행 제어 명령어의 목적 주소만으로 공격을 탐지하기 때문에 트램폴린 함수를 호출하는 프로그램에 대해서는 정상적인 제어 흐름이지만 공격으로 탐지하고, retum-to-Hbc 공격 기법의 경우 탐지하지 못함을 확인할 수 있었다. 트램폴린 함수와 관련된 문제점은 트램폴린 함수를 사용하는 프로그램을 재작성함으로써 해결할 수 있으나 retum-to-Hbc 공격의 경우 공격을 탐지할 수 있는 다른 방법을 강구하여야 한다.
참고문헌 (17)
AlephOne, Smashing the Stack for Fun and Profit, Phrack, Volume 7, Issue 49, http://www.phrack.org/phrack/49/P49-14, 1996.11
Matt Conover and w00w00 Security Team, w00w00 on Heap Overflows, http://www.w00w00.org/files/articles/heaptut/txt, 1999.1
Tim Newsham, Format String Attacks - White Paper, http://www.lava.net/~newsham/format-string-attacks.pdf, Setp., 2000
CERT Condination Center, http://www.cert.org/advisories
Crispin Cowan, Perry Wagle, Calton Pu, Steve Beattie and Jonathan Walpole, 'Buffer Overflows: Attack and Defenses for the Vulnerability of the Decade,' DARPA Information Survivability Conference and Exposition (DISCEX 2000), Jan., 2000
John Wilander and Mariam Kamkar, 'A Comparison of Publicly Available Tools for Dynamic Buffer Overflow Prevention,' Network and Distributed System Security Symposium (NDSS) '03, Feb., 2003
Crispin Cowan, Calton Pu, Dave Maier, Jonathan Walpole, Peat Bakke, Steve Beattie, Aaron Grier, Perry Wagle, Qian Zhang and Heather Hinton, 'StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks,' 7th USENIX Security Symposium, Jan., 1998
Vendicator, StakShield: A Stack Smashing Technique Protection Tool for Linux, http://www.angelfire.com/sk/stackshield
Hiroaki Etoh and Kunikazu Yoda, Protecting from Stacksmashing Attacks, http://www.trl.ibm.com/projects/security/ssp/main.html, Jun., 2000
김종의, 이성욱, 홍만표, '버퍼오버플로우 공격 방지를 위한 컴파일러 기법,' 정보처리학회논문지C, 제9-C권 제4호, pp.453-458, 2002
Microsoft, Microsoft Security Developer Center, http://msdn.microsoft.com/security/
Microsoft, Changes to Functionality in Microsoft Windows XP Service Pack 2 - Part 3: Memory Protection Technologies, http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2mempr.mspx
Daniel Bovet and Marco Cesati, Understanding the LINUX Kernel: From I/O Ports to Process Management, 2nd Ed., pp.670-672, Dec., 2002
Peter Silberman and Richard Johnson, 'A Comparison of Buffer Overflow Prevention Implementations and Their Weaknesses,' Black Hat USA 2004 Briefings and Training, Jun., 2004
※ AI-Helper는 부적절한 답변을 할 수 있습니다.