버퍼 오버플로

Buffer overflow
소프트웨어 버퍼 오버플로의 시각화.데이터는 A에 쓰이지만 A에 들어가기에는 너무 커서 B에 넘칩니다.

정보 보안 및 프로그래밍에서 버퍼 오버플로 또는 버퍼 오버런은 버퍼에 데이터를 쓰는 동안 프로그램이 버퍼의 경계를 오버런하여 인접한 메모리 위치를 덮어쓰는 이상 현상입니다.

버퍼는 데이터를 저장하기 위해 남겨진 메모리의 영역이며, 종종 프로그램의 한 섹션에서 다른 섹션으로 또는 프로그램 간에 데이터를 이동할 때 사용됩니다.버퍼 오버플로우는 잘못된 입력에 의해 트리거되는 경우가 많습니다.모든 입력이 특정 크기보다 작다고 가정하고 버퍼가 그 크기로 작성되면 더 많은 데이터가 생성되는 비정상적인 트랜잭션으로 버퍼의 끝을 지나 쓸 수 있습니다.이로 인해 인접한 데이터 또는 실행 가능한 코드가 덮어쓰게 되면 메모리 액세스 오류, 잘못된 결과, 크래시 등 불규칙한 프로그램 동작이 발생할 수 있습니다.

버퍼 오버플로의 동작을 부정 이용하는 것은 잘 알려진 보안 부정 이용입니다.많은 시스템에서 프로그램 또는 시스템 전체의 메모리 레이아웃이 잘 정의되어 있습니다.버퍼 오버플로를 일으키도록 설계된 데이터를 송신함으로써 실행 가능 코드를 보유하고 있는 것으로 알려진 영역에 기입하여 악성 코드로 대체하거나 프로그램 상태에 관련된 데이터를 선택적으로 덮어쓸 수 있으므로 원래 프로그래머가 의도하지 않았던 동작을 발생시킬 수 있다.버퍼는 운영체제(OS) 코드에 널리 포함되어 있기 때문에 권한 상승 및 컴퓨터 리소스에 대한 무제한 액세스를 수행하는 공격이 발생할 수 있습니다.1988년에 유명한 모리스 웜은 이것을 공격 기술 중 하나로 사용했다.

버퍼 오버플로우와 일반적으로 관련된 프로그래밍 언어에는 C 및 C++가 포함됩니다.이 언어들은 메모리의 어떤 부분에서도 데이터에 대한 접근이나 덮어쓰기 방지 기능을 제공하지 않으며 어레이(내장 버퍼 타입)에 기입된 데이터가 해당 어레이의 경계 내에 있는지 자동으로 체크하지 않습니다.경계 검사를 통해 버퍼 오버플로를 방지할 수 있지만 추가 코드와 처리 시간이 필요합니다.최신 운영 체제에서는 특히 메모리 레이아웃을 랜덤화하거나 버퍼 사이에 의도적으로 공간을 두고 이러한 영역에 쓰는 작업("카나리아")을 찾는 등 다양한 기술을 사용하여 악의적인 버퍼 오버플로에 대처합니다.

기술 설명

버퍼 오버플로는 버퍼에 기입된 데이터도 충분한 경계체크로 인해 행선지 버퍼에 인접한 메모리주소의 데이터 값이 파손되었을 경우에 발생합니다.이 문제는 데이터가 수신인 버퍼에 적합한지 먼저 확인하지 않고 버퍼 간에 데이터를 복사할 때 발생할 수 있습니다.

예

스택 기반 오버플로우의 상세 정보:스택 버퍼 오버플로

C로 나타낸 다음 예에서는 프로그램에는 메모리 내에 인접해 있는2개의 변수, 즉 8바이트 길이의 문자열 버퍼 A와 2바이트의 빅 엔디안 정수 B가 있습니다.

차           A[8] = ""; 서명되어 있지 않다 짧다 B    = 1979;

처음에 A에는 0바이트만 포함되며 B에는 1979라는 번호가 포함됩니다.

변수명 A B
가치 [현악기억울] 1979
16진수치 00 00 00 00 00 00 00 00 07 BB

이 시점에서 프로그램은 null로 종단된 문자열을 저장하려고 합니다. "excessive"A 버퍼에 ASCII 인코딩이 포함되어 있습니다. 

스트럭시(A, "실패");

"excessive"는 9자로 늘 터미네이터를 포함하여 10바이트로 인코딩되지만 A는 8바이트밖에 사용할 수 없습니다.문자열의 길이를 확인하지 않으면 B: 값도 덮어씁니다.

변수명 A B
가치 'e' 'x' 'c' 'e' 's' 's' 'i' 'v' 25856
16진수 65 78 63 65 73 73 69 76 65 00

B의 값이 문자열의 일부에서 형성된 숫자로 잘못 대체되었습니다.이 예에서 "e" 뒤에 0바이트가 계속되면 25856이 됩니다.

할당된 메모리의 끝을 지난 데이터 쓰기가 운영 체제에 의해 감지되어 프로세스를 종료하는 분할 오류 오류가 발생할 수 있습니다.

이 예에서는 버퍼 오버플로의 발생을 방지하기 위해 에 대한 콜을 로 대체할 수 있습니다.이 예에서는 A의 최대 캐퍼시티(늘 종단 문자 포함)를 추가 파라미터로 사용하여 A에 기입할 수 있는 데이터의 양이 이 이하가 되도록 합니다.

스트릭(A, "실패", 크기(A));

사용 가능한 경우 소스 문자열의 길이가 버퍼 크기(함수에 전달된 세 번째 인수)보다 크거나 같으면 라이브러리 함수가 대상 버퍼를 null로 종단하지 않으므로 null로 종단되지 않고 유효한 C 스타일 문자열로 취급할 수 없습니다.

이용

버퍼 오버플로 취약성을 부정 이용하는 방법은 아키텍처, 운영 체제 및 메모리 영역에 따라 다릅니다.예를 들어 힙에서의 부정 이용(동적으로 할당된 메모리에 사용)은 콜스택에서의 부정 이용과는 현저하게 다릅니다.

스택 기반 공격

주요 기사:스택 버퍼 오버플로

기술적인 경향이 있는 사용자는 스택 기반 버퍼 오버플로를 이용하여 프로그램을 여러 가지 방법 중 하나로 조작할 수 있습니다.

  • 프로그램의 동작을 변경하기 위해 스택의 취약한 버퍼 근처에 있는 로컬 변수를 덮어씁니다.
  • 스택 프레임 내의 반환 주소를 공격자가 선택한 코드(일반적으로 셸 코드)를 가리키도록 덮어씁니다.함수가 반환되면 공격자의 셸 코드로 실행이 재개됩니다.
  • 셸[1] 코드를 가리키도록 함수 포인터 또는 예외 핸들러를 덮어쓰면 나중에 실행됩니다.
  • 다른 스택 프레임의 로컬 변수(또는 포인터)를 덮어쓰면 나중에 [2]해당 프레임을 소유하는 함수에 의해 사용됩니다.

공격자는 이러한 공격 중 하나를 일으키도록 데이터를 설계한 다음 취약한 코드에 의해 사용자에게 제공된 버퍼에 이 데이터를 저장합니다.스택 버퍼 오버플로의 영향을 받기 위해 사용되는 사용자 제공 데이터의 주소를 예측할 수 없는 경우 스택 버퍼 오버플로를 이용하여 리모트코드를 실행하는 것은 훨씬 어려워집니다.이러한 버퍼 오버플로를 부정 이용하는 데 사용할 수 있는 기술을 "트램폴리닝"이라고 합니다.이 기술에서는 공격자가 취약한 스택버퍼에 대한 포인터를 찾아 해당 포인터에 상대적인 셸 코드의 위치를 계산합니다.그런 다음 덮어쓰기를 사용하여 메모리에 이미 있는 명령으로 점프합니다. 이때 포인터에 대해 두 번째 점프를 수행합니다. 두 번째 점프는 셸 코드로 실행을 분기합니다.적절한 명령어는 큰 코드로 표시되는 경우가 많습니다.예를 들어 Metasploit 프로젝트는 적절한 운영 [3]코드의 데이터베이스를 유지 관리하지만 윈도우즈 운영 체제에 있는 운영 코드만 나열합니다.

힙 기반 공격

주요 기사:힙 오버플로

히프 데이터 영역에서 발생하는 버퍼 오버플로는 히프 오버플로라고 불리며 스택 기반 오버플로와는 다른 방식으로 이용 가능합니다.힙의 메모리는 런타임에 응용 프로그램에 의해 동적으로 할당되며 일반적으로 프로그램 데이터가 포함됩니다.공격이 수행하려면 특정 방법으로 이 데이터를 손상하여 응용 프로그램이 연결된 목록 포인터와 같은 내부 구조를 덮어쓰도록 합니다.표준 힙 오버플로 기술은 동적 메모리 할당 링크(예: malloc 메타 데이터)를 덮어쓰고 결과 포인터 교환을 사용하여 프로그램 함수 포인터를 덮어씁니다.

Microsoft의 JPEG 처리에서의 GDI+ 취약성은 힙 오버플로가 발생할 [4]수 있는 위험의 한 예입니다.

이용의 장벽

버퍼를 읽거나 실행하기 전에 버퍼를 조작하면 부정 이용 시도가 실패할 수 있습니다.이러한 조작을 통해 부정 이용의 위협을 완화할 수 있지만 이를 불가능하게 만들 수는 없습니다.조작에는 대문자 또는 소문자로 변환, 메타 문자 제거 및 영숫자가 아닌 문자열에서 필터링이 포함될 수 있습니다.단, 영숫자 셸 코드, 다형성 코드, 자가 수정 코드 및 Return-to-libc 공격 등 이러한 필터와 조작을 바이패스하는 기술이 존재합니다.침입 탐지 시스템에 의한 탐지를 방지하기 위해 동일한 방법을 사용할 수 있습니다.코드가 [5]Unicode로 변환되는 경우를 포함하여 실제로 임의 코드를 원격으로 실행할 수 있는 경우, 이 취약성의 위협이 공개자에 의해 Denial of Service(서비스 거부)로만 잘못 표현된 경우도 있습니다.

이용의 실용성

실제 악용에서는 악용이 안정적으로 작동하기 위해 극복해야 하는 다양한 과제가 있습니다.이러한 요인에는 주소의 늘바이트, 셸 코드 위치의 가변성, 환경 간의 차이 및 작동 중인 다양한 대책 등이 포함됩니다.

NOP 스레드 기술

주요 기사: NOP 슬라이드
스택상의 NOP슬레이드 페이로드 그림.

NOP-sled는 스택버퍼 [6]오버플로우를 부정 이용하는 가장 오래된 기술입니다.대상 영역의 크기를 효과적으로 늘림으로써 버퍼의 정확한 주소를 찾는 문제를 해결합니다.이렇게 하려면 no-op 머신 명령으로 스택의 더 큰 섹션이 파손됩니다.공격자가 제공한 데이터의 마지막에, no-op 명령 후에, 공격자는 셸 코드가 있는 버퍼의 상부에 상대적인 점프를 실행하도록 지시합니다.이 no-ops 컬렉션은 'NOP-sled'라고 불립니다.이는 반환 주소가 버퍼의 no-op 영역 내의 주소로 덮어쓰면 실행이 마지막에 점프를 통해 실제 악성 코드로 리다이렉트될 때까지 no-ops를 "슬라이드"하기 때문입니다.이 방법에서는 공격자가 비교적 작은 셸 [7]코드 대신 NOP가 스택에서 어디에 있는지 추측해야 합니다.

이 기술의 보급으로 많은 침입 방지 시스템 벤더가 사용 중인 셸 코드를 검출하기 위해 이 no-op 머신 명령 패턴을 검색합니다.NOP-sled에 반드시 기존의 no-op 머신 명령만 포함되어 있는 것은 아닙니다.셸 코드가 실행되지 않을 정도로 머신 상태가 손상되지 않는 명령어는 하드웨어 지원 no-op 대신 사용할 수 있습니다.그 결과, 부정 이용 라이터는 셸 [8]코드 실행에 실질적인 영향을 미치지 않는 임의의 명령으로 no-op 스레드를 구성하는 것이 일반적인 관례가 되었습니다.

이 방법을 사용하면 공격이 성공할 가능성이 크게 향상되지만 문제가 없는 것은 아닙니다.이 기술을 사용하는 부정 이용은 NOP슬레드 [9]영역 내에 있는 스택의 오프셋을 추측할 수 있는 행운에 의존해야 합니다.추측이 틀리면 일반적으로 대상 프로그램이 충돌하고 시스템 관리자에게 공격자의 활동에 대해 경고할 수 있습니다.또 다른 문제는 NOP-sled에는 NOP-sled를 사용할 수 있을 만큼 큰 용량의 메모리가 필요하다는 것입니다.이 문제는 영향을 받는 버퍼의 할당된 크기가 너무 작고 스택의 현재 깊이가 얕을 때(즉, 현재 스택프레임의 끝에서 스택의 시작까지 공간이 많지 않은 경우) 발생할 수 있습니다.NOP-sled는 문제에도 불구하고 특정 플랫폼, 환경 또는 상황에 적합한 유일한 방법이며, 여전히 중요한 기술입니다.

레지스터 기법에 저장된 주소로 이동

"jump to register" 기술을 사용하면 NOP에 의한 추가 공간이나 스택오프셋을 추측할 필요 없이 스택버퍼 오버플로우를 신뢰성 있게 이용할 수 있습니다.이 전략은 프로그램이 제어된 버퍼와 셸 코드를 가리키는 레지스터 내에 저장된 알려진 포인터로 점프하도록 하는 무언가로 리턴 포인터를 덮어쓰는 것입니다.예를 들어 레지스터 A에 버퍼 시작 포인터가 포함되어 있는 경우 해당 레지스터를 오퍼랜드로 하는 점프 또는 콜을 사용하여 [10]실행 흐름을 제어할 수 있습니다.

ntdll.dll로부터의 명령으로DbgPrint()루틴에 i386 머신의 opcode가 포함되어 있습니다.jmp esp.

실제 프로그램에는 특정 레지스터로 점프하기 위한 명령이 의도적으로 포함되어 있지 않을 수 있습니다.기존의 솔루션은 프로그램 메모리 내의 고정 위치에서 의도하지 않은 적절한 opcode 인스턴스를 찾는 것입니다.왼쪽 그림 E는 i386의 의도하지 않은 예를 나타냅니다.jmp esp설명.이 명령의 opcode는 다음과 같습니다.FF E4이 2바이트 시퀀스는 명령 시작부터 1바이트 오프셋으로 찾을 수 있습니다.[11]call DbgPrint어드레스로0x7C941EED공격자가 프로그램 반환 주소를 이 주소로 덮어쓰면 프로그램은 먼저 로 이동합니다.0x7C941EED, opcode를 해석합니다.FF E4처럼jmp esp스택의 맨 위로 점프하여 공격자 코드를 [12]실행합니다.

이 기술이 가능해지면 취약성의 심각도가 상당히 높아집니다.그 이유는 공격이 실행될 때 공격을 자동화할 수 있을 만큼 충분히 안정적으로 작동하여 가상적인 성공을 보장하기 때문입니다.따라서 이는 스택버퍼 오버플로 [13]취약성을 부정 이용하는 인터넷 웜에서 가장 일반적으로 사용되는 기술입니다.

또, 이 방법을 사용하면, Windows 플랫폼의 덧쓰기된 리턴 주소 뒤에 셸 코드를 배치할 수도 있습니다.실행 파일은 대부분 주소에 기반하기 때문에0x00400000x86은 Little Endian 아키텍처입니다.리턴 주소의 마지막 바이트는 늘이어야 합니다.버퍼 복사는 종료되고 그 이외에는 아무것도 기입되지 않습니다.이것에 의해, 셸 코드의 사이즈가 버퍼의 사이즈로 제한되기 때문에, 지나치게 제한될 가능성이 있습니다.DLL은 대용량 메모리에 배치되어 있습니다(위).0x01000000null 바이트를 포함하지 않는 주소도 있기 때문에 이 방법을 사용하면 덮어쓰기된 반환 주소에서 null 바이트(또는 기타 허용되지 않는 문자)를 삭제할 수 있습니다.이 방법으로 사용되는 방법은 종종 "DLL 트램펄리닝"이라고 불립니다.

보호대책

버퍼 오버플로를 검출 또는 방지하기 위해 다양한 기술이 사용되어 왔습니다.버퍼 오버플로를 회피하거나 방지하는 가장 신뢰할 수 있는 방법은 언어 수준에서 자동 보호를 사용하는 것입니다.그러나 이러한 종류의 보호는 레거시 코드에 적용할 수 없으며 기술, 비즈니스 또는 문화적 제약으로 인해 취약한 언어가 필요한 경우가 많습니다.다음 항에서는 사용 가능한 선택지와 구현에 대해 설명합니다.

프로그래밍 언어 선택

어셈블리와 C/C++는 버퍼 오버플로의 영향을 받기 쉬운 일반적인 프로그래밍 언어입니다.이는 부분적으로 메모리에 대한 직접 접근을 허용하고 강하게 [14]입력되지 않기 때문입니다.C는, 메모리의 어느 부분에서도 데이터에 액세스 하거나 데이터를 덮어쓰는 것에 대해서, 빌트인 보호를 제공하지 않습니다.구체적으로는 버퍼에 기입된 데이터가 그 버퍼의 경계내에 있는지 체크하지 않습니다.표준 C++ 라이브러리는 데이터를 안전하게 버퍼링하는 많은 방법을 제공하며, C++의 STL(Standard Template Library)은 프로그래머가 데이터에 액세스하는 동안 검사를 명시적으로 호출하는 경우 선택적으로 경계 검사를 수행할 수 있는 컨테이너를 제공합니다.예를 들어,vector의 멤버 함수at()경계체크를 실행하여 를 슬로우합니다.out_of_range 예외로 설정합니다.[15]단, 경계체크가 명시적으로 호출되지 않은 경우 C++는 C와 동일하게 동작합니다.C에는 버퍼 오버플로우를 회피하는 방법도 있습니다.

COBOL, Java, Python 등 강력한 타입으로 직접 메모리 액세스가 허용되지 않는 언어는 대부분의 [14]경우 버퍼 오버플로가 발생하는 것을 방지합니다.C/C++ 이외의 많은 프로그래밍 언어는 런타임 체크와 경우에 따라서는 C 또는 C++가 데이터를 덮어쓰고 프로그램이 크래시되거나 크래시되지 않을 수 있는 잘못된 결과를 얻을 때까지 경고를 보내거나 예외를 발생시킬 수 있습니다.이러한 언어의 예로는 Ada, Eiffel, Lisp, Modula-2, Smalltalk, OCaml 및 사이클론, 녹, D와 같은 C 파생어가 있다.자바와또, NET Framework 바이트 코드 환경에서는, 모든 어레이의 경계 체크가 필요합니다.거의 모든 인터프리터 언어가 버퍼 오버플로우로부터 보호되어 명확하게 정의된 오류 상태를 나타냅니다.언어에서 범위 검사를 수행할 수 있는 충분한 유형 정보를 제공하는 경우 옵션을 활성화하거나 비활성화하기 위한 옵션이 제공되는 경우가 많습니다.정적 코드 분석을 통해 많은 동적 바인딩 및 유형 검사를 제거할 수 있지만, 구현 상태가 나쁘거나 문제가 있는 경우 성능이 크게 저하될 수 있습니다.소프트웨어 엔지니어는 사용할 언어와 컴파일러 설정을 결정할 때 안전 비용과 성능 비용의 균형을 신중하게 고려해야 합니다.

안전한 라이브러리 사용

버퍼 오버플로우 문제는 C 및 C++ 언어에서 흔히 볼 수 있습니다.이는 버퍼의 낮은 수준의 표현 세부사항을 데이터 유형의 컨테이너로 노출하기 때문입니다.따라서 버퍼 관리를 수행하는 코드에서 높은 수준의 정확성을 유지함으로써 버퍼 오버플로를 방지해야 합니다.또한 다음과 같이 경계를 검사하지 않는 표준 라이브러리 기능은 피하는 것이 좋습니다.gets,scanf그리고.strcpyMorris 웜은 그 벌레를 이용해gets핑거드에게 [16]전화하다

적절하게 작성되고 테스트된 추상 데이터 유형 라이브러리를 사용하면 버퍼 오버플로의 발생과 영향을 줄일 수 있습니다.이 라이브러리는 경계 검사를 포함하여 버퍼 관리를 일원화하고 자동으로 수행합니다.이러한 언어에서 버퍼 오버플로우가 일반적으로 발생하는 2가지 주요 빌딩 블록 데이터 유형은 문자열과 배열입니다.따라서 이러한 데이터 유형의 버퍼 오버플로우를 방지하는 라이브러리는 필요한 커버리지의 대부분을 제공할 수 있습니다.그러나 이러한 안전한 라이브러리를 올바르게 사용하지 않으면 버퍼 오버플로우 및 기타 취약성이 발생할 수 있습니다.또한 라이브러리 내의 버그 자체가 잠재적인 취약성일 수도 있습니다."안전한" 라이브러리 구현에는 "더 베터 스트링 라이브러리",[17] Vstr[18] 및 [19]Erwin이 포함됩니다.오픈비SD 운영 체제의 C 라이브러리는 strlcpy 및 strlcat 기능을 제공하지만, 이러한 기능은 완전한 안전한 라이브러리 구현보다 더 제한적입니다.

2007년 9월에는 C 표준위원회에 의해 작성된 기술 보고서 24731이 [20]발행되었습니다.이 보고서에서는 표준 C 라이브러리의 문자열과 I/O 함수에 기반한 기능 집합과 추가 버퍼 크기 매개변수를 명시하고 있습니다.단, 버퍼 오버플로우를 줄이기 위한 이들 함수의 효율성은 논란의 여지가 있습니다.이는 유사한 오래된 표준 라이브러리 함수의 버퍼 오버플로우를 안전하게 할 [21]수 있는 개입과 동등한 함수별 호출 기준으로 프로그래머의 개입이 필요합니다.

버퍼 오버플로 보호

주요 기사: 버퍼 오버플로우 방지

버퍼 오버플로우 보호는 함수가 반환되었을 때 스택이 변경되지 않았는지 확인함으로써 가장 일반적인 버퍼 오버플로우를 검출하기 위해 사용됩니다.변경된 경우 분할 오류와 함께 프로그램이 종료됩니다.Libsafe와 [22]StackGuard[23] 및 ProPolice[24] gcc 패치의 3가지 시스템이 있습니다.

Microsoft의 DEP(Data Execution Prevention) 모드 구현은 SEH(Structured Exception Handler)에 대한 포인터를 [25]덮어쓰지 않도록 명시적으로 보호합니다.

스택을 데이터용과 함수 반환용 두 가지로 분할함으로써 스택 보호를 강화할 수 있습니다.이 분할은 Fourth 언어로 표시되지만 보안 기반 설계 결정은 아닙니다.단, 리턴 주소 이외의 기밀 데이터는 덮어쓸 수 있기 때문에 버퍼 오버플로의 완전한 솔루션은 아닙니다.

포인터 보호

버퍼 오버플로는 저장된 주소를 포함하여 포인터를 조작함으로써 작동합니다.PointGuard는 공격자가 포인터와 [26]주소를 안정적으로 조작하는 것을 방지하기 위해 컴파일러 확장으로 제안되었습니다.이 접근법은 컴파일러가 포인터가 사용되기 전후에 자동으로 XOR-encode 포인터에 코드를 추가함으로써 동작합니다.이론적으로 공격자는 포인터의 부호화/복호화에 사용되는 값을 모르기 때문에 새로운 값으로 덮어쓸 경우 포인터가 무엇을 가리킬지 예측할 수 없습니다.PointGuard는 출시되지 않았지만 Microsoft는 Windows XP SP2 및 Windows Server 2003 [27]SP1부터 동일한 접근방식을 구현했습니다.Microsoft는 포인터 보호를 자동 기능으로 구현하지 않고 호출 가능한 API 루틴을 추가했습니다.이것에 의해, 퍼포먼스가 향상됩니다(항상 사용되는 것은 아니기 때문에).다만, 프로그래머가 필요한 타이밍을 파악하는 것은 부담이 됩니다.

XOR은 선형이기 때문에 공격자는 주소의 하위 바이트만 덮어쓰면서 인코딩된 포인터를 조작할 수 있습니다.이를 통해 공격자가 공격을 여러 번 시도할 수 있거나 포인터가 여러 위치 중 하나(NOP [28]스레드 내의 임의의 위치 등)를 가리키도록 함으로써 공격을 완료할 수 있는 경우 공격이 성공할 수 있습니다.Microsoft 는, 부호화 스킴에 랜덤 회전을 추가해, 부분적인 [29]덮어쓰기의 이 약점을 해결했습니다.

실행 가능한 공간 보호

주요 기사:실행 가능한 공간 보호

실행 가능 공간 보호는 스택 또는 힙에서 코드가 실행되지 않도록 하는 버퍼 오버플로우 보호 방법입니다.공격자는 버퍼 오버플로를 사용하여 프로그램 메모리에 임의 코드를 삽입할 수 있지만 실행 가능한 공간 보호를 사용하면 해당 코드를 실행하려고 하면 예외가 발생합니다.

일부 CPU는 NX("No eXecute") 또는 XD("eXecute Disabled") 비트라는 기능을 지원합니다.이 기능을 소프트웨어와 함께 사용하면 데이터 페이지(스택 및 힙 포함 페이지 등)를 읽기 및 쓰기 가능하지만 실행 가능하지는 않습니다.

일부 Unix 운영 체제(예: OpenBSD, macOS)에는 실행 가능한 공간 보호 기능(예: W^X)이 포함되어 있습니다.옵션 패키지에는 다음과 같은 것이 있습니다.

최신 버전의 마이크로소프트 윈도우즈에서는 데이터 실행 방지라는 실행 [33]공간 보호도 지원합니다.독자적인 애드온에는 다음이 포함됩니다.

실행 가능한 공간 보호는 일반적으로 Return-to-libc 공격이나 공격자 코드의 실행에 의존하지 않는 다른 공격으로부터 보호되지 않습니다.그러나 ASLR을 사용하는 64비트 시스템에서는 다음과 같이 실행 가능한 공간 보호 기능을 사용하면 이러한 공격을 실행하는 것이 훨씬 더 어려워집니다.

주소 공간 레이아웃 랜덤화

주요 기사:주소 공간 레이아웃 랜덤화

ASLR(Address Space Layout Randomization)은 실행 파일의 베이스와 라이브러리, 힙 및 스택의 위치를 포함하는 주요 데이터 영역의 위치를 프로세스의 주소 공간에 무작위로 배열하는 컴퓨터 보안 기능입니다.

함수 및 변수를 찾을 수 있는 가상 메모리 주소를 랜덤화하면 버퍼 오버플로의 부정 이용은 더욱 어려워지지만 불가능하지는 않습니다.또한 공격자가 공격 시도를 개별 시스템에 맞게 조정하도록 강제하여 인터넷 [36]웜의 시도를 저지합니다.가상 주소 공간에서 프로세스와 라이브러리를 기본화하는 방법도 비슷하지만 효과적이지 않습니다.

딥 패킷인스펙션

주요 기사:딥 패킷인스펙션

Deep Packet Inspection(DPI; 딥 패킷인스펙션)을 사용하면 공격 시그니처와 휴리스틱을 사용하여 버퍼 오버플로를 부정 이용하는 매우 기본적인 리모트 시도를 네트워크 경계에서 검출할 수 있습니다.이러한 명령어는 기존의 공격의 시그니처를 가진 패킷을 차단할 수 있습니다.또한 일련의 No-Operation 명령(NOP-sled로 알려져 있음)이 검출되었을 경우, 부정 이용의 페이로드의 위치가 약간 변동하는 경우에 한 번 사용되었습니다.

패킷 스캔은 기존의 공격만 막을 수 있고 NOP-sled를 부호화할 수 있는 방법은 다양하기 때문에 효과적인 방법이 아닙니다.공격자가 사용하는 셸 코드는 영숫자, 변성 또는 자기변형을 통해 경험적 패킷스캐너 및 침입검출시스템에 의한 검출을 회피할 수 있습니다.

테스트

버퍼 오버플로우를 체크하고 자연스럽게 발생하는 버그를 패치하면 버퍼 오버플로우를 방지할 수 있습니다.그것들을 검출하기 위한 일반적인 자동화 기술 중 하나는 퍼징이다.[37]엣지 케이스 테스트에서는 정적 [38]분석과 마찬가지로 버퍼 오버플로우도 검출할 수 있습니다.잠재적인 버퍼 오버플로를 검출하면 패치를 적용해야 합니다.이것에 의해, 개발중의 소프트웨어에서는 테스트의 어프로치가 유효하게 됩니다만, 보수나 서포트를 받지 않게 된 레거시 소프트웨어에서는 그다지 유용하지 않습니다.

역사

버퍼 오버플로우는 1972년 컴퓨터 보안 기술 계획 연구(Computer Security Technology Planning Study)가 "이 기능을 수행하는 코드가 송신원 및 수신처 주소를 제대로 검사하지 않아 사용자가 모니터의 일부를 오버레이할 수 있습니다.이를 통해 사용자가 [39]머신을 제어할 수 있는 코드를 모니터에 주입할 수 있습니다."현재 모니터는 커널이라고 불립니다.

버퍼 오버플로에 대한 가장 오래된 적대적 이용은 1988년이었다.모리스 웜이 인터넷을 통해 전파하기 위해 사용한 여러 공격 중 하나였습니다.악용된 프로그램은 [40]Unix에서 핑거라고 불리는 서비스입니다.이후 1995년 Thomas Lopatic은 독립적으로 버퍼 오버플로를 재발견하여 Bugtraq 보안 메일링 [41]목록에 결과를 게시했습니다.1년 후인 1996년 Elias Levy(일명 Aleph One)는 스택 기반의 버퍼 오버플로 취약성을 이용하기 위한 단계별 소개인 논문 "Smasing the Stack for Fun and Profit"[42]을 Prack 매거진에 게재했습니다.

그 후 적어도2개의 주요 인터넷 웜이 버퍼 오버플로를 이용하여 다수의 시스템을 손상시켰습니다.2001년에는 Code Red 웜이 Microsoft의 Internet Information Services(IIS) 5.0 버퍼[43] 오버플로를 부정 이용했으며 2003년에는 SQL Slammer 웜이 Microsoft SQL Server [44]2000을 실행하는 머신을 손상시켰습니다.

2003년 Xbox 게임에 존재하는 버퍼 오버플로우는 홈브루 게임을 포함한 라이선스되지 않은 소프트웨어가 모뎀 [45]칩으로 알려진 하드웨어를 변경할 필요 없이 콘솔에서 실행될 수 있도록 하기 위해 악용되었습니다.PS2 인디펜던스 익스플로잇에서는 버퍼 오버플로를 사용하여 PlayStation 2에서도 동일한 기능을 구현했습니다.트와일라잇 해킹은 젤다의 전설에서 버퍼 오버플로를 사용하여 Wii에서도 같은 성과를 거두었다. 트와일라잇 프린세스

「 」를 참조해 주세요.

레퍼런스

  1. ^ "CORE-2007-0219: OpenBSD's IPv6 mbufs remote kernel buffer overflow". Retrieved 2007-05-15.
  2. ^ "Modern Overflow Targets" (PDF). Retrieved 2013-07-05.
  3. ^ "The Metasploit Opcode Database". Archived from the original on 12 May 2007. Retrieved 2007-05-15.
  4. ^ "Microsoft Technet Security Bulletin MS04-028". Microsoft. Archived from the original on 2011-08-04. Retrieved 2007-05-15.
  5. ^ "Creating Arbitrary Shellcode In Unicode Expanded Strings" (PDF). Archived from the original (PDF) on 2006-01-05. Retrieved 2007-05-15.
  6. ^ Vangelis (2004-12-08). "Stack-based Overflow Exploit: Introduction to Classical and Advanced Overflow Technique". Wowhacker via Neworder. Archived from the original (text) on August 18, 2007. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  7. ^ Balaban, Murat. "Buffer Overflows Demystified" (text). Enderunix.org. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  8. ^ Akritidis, P.; Evangelos P. Markatos; M. Polychronakis; Kostas D. Anagnostakis (2005). "STRIDE: Polymorphic Sled Detection through Instruction Sequence Analysis." (PDF). Proceedings of the 20th IFIP International Information Security Conference (IFIP/SEC 2005). IFIP International Information Security Conference. Archived from the original (PDF) on 2012-09-01. Retrieved 2012-03-04.
  9. ^ Klein, Christian (September 2004). "Buffer Overflow" (PDF). Archived from the original (PDF) on 2007-09-28. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  10. ^ Shah, Saumil (2006). "Writing Metasploit Plugins: from vulnerability to exploit" (PDF). Hack In The Box. Kuala Lumpur. Retrieved 2012-03-04.
  11. ^ Intel 64 and IA-32 Architectures Software Developer's Manual Volume 2A: Instruction Set Reference, A-M (PDF). Intel Corporation. May 2007. pp. 3–508. Archived from the original (PDF) on 2007-11-29.
  12. ^ Alvarez, Sergio (2004-09-05). "Win32 Stack BufferOverFlow Real Life Vuln-Dev Process" (PDF). IT Security Consulting. Retrieved 2012-03-04. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  13. ^ Ukai, Yuji; Soeder, Derek; Permeh, Ryan (2004). "Environment Dependencies in Windows Exploitation". BlackHat Japan. Japan: eEye Digital Security. Retrieved 2012-03-04.
  14. ^ a b https://www.owasp.org/index.php/Buffer_OverflowsBuffer Wayback Machine에서 OWASP Archived 2016-08-29 관련 기사 오버플로우
  15. ^ "vector::at - C++ Reference". Cplusplus.com. Retrieved 2014-03-27.
  16. ^ "Archived copy". wiretap.area.com. Archived from the original on 5 May 2001. Retrieved 6 June 2022.{{cite web}}: CS1 maint: 제목으로 아카이브된 복사(링크)
  17. ^ "The Better String Library".
  18. ^ "The Vstr Homepage". Archived from the original on 2017-03-05. Retrieved 2007-05-15.
  19. ^ "The Erwin Homepage". Retrieved 2007-05-15.
  20. ^ International Organization for Standardization (2007). "Information technology – Programming languages, their environments and system software interfaces – Extensions to the C library – Part 1: Bounds-checking interfaces". ISO Online Browsing Platform.
  21. ^ "CERT Secure Coding Initiative". Archived from the original on December 28, 2012. Retrieved 2007-07-30.
  22. ^ "Libsafe at FSF.org". Retrieved 2007-05-20.
  23. ^ "StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks by Cowan et al" (PDF). Retrieved 2007-05-20.
  24. ^ "ProPolice at X.ORG". Archived from the original on 12 February 2007. Retrieved 2007-05-20.
  25. ^ "Bypassing Windows Hardware-enforced Data Execution Prevention". Archived from the original on 2007-04-30. Retrieved 2007-05-20.
  26. ^ "12th USENIX Security Symposium – Technical Paper". www.usenix.org. Retrieved 3 April 2018.
  27. ^ "Protecting against Pointer Subterfuge (Kinda!)". msdn.com. Archived from the original on 2010-05-02. Retrieved 3 April 2018.
  28. ^ "USENIX - The Advanced Computing Systems Association" (PDF). www.usenix.org. Retrieved 3 April 2018.
  29. ^ "Protecting against Pointer Subterfuge (Redux)". msdn.com. Archived from the original on 2009-12-19. Retrieved 3 April 2018.
  30. ^ "PaX: Homepage of the PaX team". Retrieved 2007-06-03.
  31. ^ "KernelTrap.Org". Archived from the original on 2012-05-29. Retrieved 2007-06-03.
  32. ^ "Openwall Linux kernel patch 2.4.34-ow1". Archived from the original on 2012-02-19. Retrieved 2007-06-03.
  33. ^ "Microsoft Technet: Data Execution Prevention". Archived from the original on 2006-06-22. Retrieved 2006-06-30.
  34. ^ "BufferShield: Prevention of Buffer Overflow Exploitation for Windows". Retrieved 2007-06-03.
  35. ^ "NGSec Stack Defender". Archived from the original on 2007-05-13. Retrieved 2007-06-03.
  36. ^ "PaX at GRSecurity.net". Retrieved 2007-06-03.
  37. ^ "The Exploitant - Security info and tutorials". Retrieved 2009-11-29.
  38. ^ Larochelle, David; Evans, David (13 August 2001). "Statically Detecting Likely Buffer Overflow Vulnerabilities". USENIX Security Symposium. 32.
  39. ^ "Computer Security Technology Planning Study" (PDF). p. 61. Archived from the original (PDF) on 2011-07-21. Retrieved 2007-11-02.
  40. ^ ""A Tour of The Worm" by Donn Seeley, University of Utah". Archived from the original on 2007-05-20. Retrieved 2007-06-03.
  41. ^ "Bugtraq security mailing list archive". Archived from the original on 2007-09-01. Retrieved 2007-06-03.
  42. ^ ""Smashing the Stack for Fun and Profit" by Aleph One". Retrieved 2012-09-05.
  43. ^ "eEye Digital Security". Retrieved 2007-06-03.
  44. ^ "Microsoft Technet Security Bulletin MS02-039". Microsoft. Archived from the original on 2008-03-07. Retrieved 2007-06-03.
  45. ^ "Hacker breaks Xbox protection without mod-chip". Archived from the original on 2007-09-27. Retrieved 2007-06-03.

외부 링크