버퍼 오버플로 보호

Buffer overflow protection

버퍼 오버플로우 보호는 스택에 할당된 변수에서 버퍼 오버플로우를 검출하여 프로그램 동작의 원인이 되거나 심각한 보안 취약성이 되는 것을 방지함으로써 실행 프로그램의 보안을 강화하기 위해 소프트웨어 개발 중에 사용되는 다양한 기술 중 하나입니다.스택 버퍼 오버플로는 프로그램이 의도된 데이터 구조(일반적으로 고정 길이 버퍼) 외부에 있는 프로그램의 콜 스택에 있는 메모리 주소에 쓸 때 발생합니다.스택 버퍼 오버플로 버그는 프로그램이 스택에 있는 버퍼에 실제로 할당된 것보다 더 많은 데이터를 쓸 때 발생합니다.이로 인해 스택 상의 인접 데이터가 거의 항상 파손되어 프로그램 크래시, 잘못된 동작 또는 보안 문제가 발생할 수 있습니다.

일반적으로 버퍼 오버플로우 보호는 스택에 할당된 데이터의 구성을 변경하여 스택버퍼 오버플로에 의해 파괴되었을 때 메모리 내의 버퍼가 오버플로우되었음을 나타내는 canari 값을 포함합니다.canari 값을 확인함으로써 영향을 받는 프로그램의 실행을 종료하여 프로그램의 동작을 방해하거나 공격자가 프로그램의 제어를 할 수 있도록 할 수 있습니다.다른 버퍼 오버플로우 방지 기술에는 할당된 각 메모리 블록에 대한 액세스를 검사하여 실제로 할당된 공간을 초과할 수 없도록 하는 경계 검사와 데이터 저장용으로 할당된 메모리에 실행 가능한 코드를 포함할 수 없도록 하는 태깅이 있습니다.

스택에 모든 활성 함수 호출의 반환 주소가 포함되어 있기 때문에 스택에 할당된 버퍼를 너무 많이 채우는 것은 힙의 버퍼를 너무 많이 채우는 것보다 프로그램 실행에 영향을 줄 가능성이 높습니다.다만, 힙 베이스의 오버플로우에 대해서는, 같은 실장 고유의 보호도 존재합니다.

버퍼 오버플로우 방지에는 GNU 컴파일러 컬렉션, LLVM, Microsoft Visual Studio 및 기타 컴파일러를 포함한 여러 가지 구현이 있습니다.

개요

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

스택 버퍼 오버플로는 프로그램이 의도된 데이터 구조(일반적으로 고정 길이 버퍼) 외부에 있는 프로그램의 콜 스택에 있는 메모리 주소에 쓸 때 발생합니다.스택 버퍼 오버플로 버그는 프로그램이 스택에 있는 버퍼에 실제로 할당된 것보다 더 많은 데이터를 쓸 때 발생합니다.이로 인해 거의 항상 스택상의 인접 데이터가 파손됩니다.또한 실수로 오버플로가 트리거된 경우에는 프로그램이 크래시되거나 올바르게 동작하지 않는 경우가 많습니다.스택 버퍼 오버플로는 버퍼 오버플로(또는 버퍼 오버런)로 알려진 보다 일반적인 프로그래밍 오동작의 일종입니다.스택에 모든 액티브함수 [1]호출의 반환 주소가 포함되어 있기 때문에 스택상의 버퍼가 과잉으로 채워지는 것보다 스택상의 버퍼가 과잉으로 채워지면 프로그램 실행이 지연될 가능성이 높아집니다.

스택 버퍼 오버플로는 스택스매싱이라고 불리는 공격의 일부로 의도적으로 발생할 수 있습니다.영향을 받는 프로그램이 특수 권한으로 실행되고 있는 경우 또는 신뢰할 수 없는 네트워크 호스트(예를 들어 퍼블릭 웹 서버)로부터 데이터를 수신하는 경우, 이 버그는 공격자가 실행 가능한 코드를 실행 중인 프로그램에 주입하고 프로세스를 제어할 수 있는 잠재적인 보안 취약성입니다.이것은 공격자가 컴퓨터에 [2]대한 무단 액세스 권한을 얻을 수 있는 가장 오래되고 신뢰할 수 있는 방법 중 하나입니다.

일반적으로 버퍼 오버플로우 보호는 함수 호출의 스택프레임 내의 데이터 구성을 변경하여 파기 시 메모리 내의 버퍼가 오버플로우되었음을 나타내는 "카나리" 값을 포함합니다.이를 통해 전체 클래스의 공격을 방지할 수 있습니다.일부 [3]연구원들에 따르면 이러한 기술의 성능에 미치는 영향은 무시할 수 있습니다.

스택 스매시 보호는 특정 형태의 공격으로부터 보호할 수 없습니다.예를 들어 힙 내의 버퍼 오버플로우로부터 보호할 수 없습니다.구조 내에서 데이터 레이아웃을 변경할 수 있는 적절한 방법은 없습니다.구조는 모듈 간, 특히 공유 라이브러리의 경우 동일할 것으로 예상됩니다.버퍼 이후의 구조 내의 데이터는 카나리아로 보호할 수 없습니다.따라서 프로그래머는 변수를 어떻게 구성하고 구조를 사용하는지 매우 주의해야 합니다.

카나리아

카나리아 또는 카나리아 워드는 버퍼 오버플로우를 감시하기 위해 스택 상의 버퍼와 제어 데이터 사이에 배치되는 기존의 값입니다.버퍼가 오버플로우하면 가장 먼저 파손되는 데이터는 보통 canari가 됩니다.따라서 canari 데이터의 검증에 실패하면 오버플로우가 경고됩니다.이러한 데이터는 예를 들어 파손된 데이터를 무효화하는 등의 방법으로 처리될 수 있습니다.canari 값은 sentinel 값과 혼동하지 마십시오.

이 용어는 탄광에서 카나리아를 사용하는 역사적 관행을 지칭하는 것으로, 카나리아가 광부보다 먼저 유독 가스의 영향을 받아 생물학적 경고 시스템을 제공하기 때문이다.카나리아는 쿠키라고 불리기도 합니다.이것은 값이 파손되었을 때 "파손된 쿠키"의 이미지를 불러오는 것을 의미합니다.

사용 중인 카나리에는 터미네이터, 랜덤 및 랜덤 XOR의 3가지 유형이 있습니다.현재 버전의 StackGuard는 3가지 모두를 지원하지만 ProPolice는 터미네이터와 랜덤 카나리아를 지원합니다.

터미네이터 카나리아

터미네이터 카나리아는 대부분의 버퍼 오버플로 공격이 문자열 터미네이터로 끝나는 특정 문자열 조작에 기반한다는 관찰을 사용합니다.이 관찰에 대한 반응은 카나리아가 늘 터미네이터, CR, LF 및 FF로 구성되어 있다는 것입니다.따라서 공격자는 반환 주소를 쓰기 전에 null 문자를 써야 canary가 변경되지 않습니다.이것에 의해, 다음의 방법으로 공격을 회피합니다.strcpy()및 null 문자를 복사한 후 반환되는 기타 메서드. 단, 바람직하지 않은 결과는 canari가 알려진 것입니다.보호 기능을 사용하더라도 공격자는 잠재적으로 알려진 값으로 canari를 덮어쓰고 일치하지 않는 값을 가진 제어 정보를 통해 canari 체크 코드를 전달할 수 있습니다.이 코드는 특정 프로세서의 호출로부터의 반환 명령 직전에 실행됩니다.

랜덤 카나리아

랜덤 카나리는 공격자가 그 값을 알아채지 못하도록 하기 위해 보통 엔트로피 수집 데몬에서 랜덤으로 생성됩니다.일반적으로 canari를 부정 이용하는 것은 논리적으로 불가능하거나 타당하지 않습니다.canari는 canari를 알아야 하는 사람만이 알고 있는 안전한 값입니다.이 경우 버퍼 오버플로우 보호 코드입니다.

일반적으로 랜덤 카나리는 프로그램 초기화 시 생성되며 글로벌 변수에 저장됩니다.이 변수는 보통 매핑되지 않은 페이지에 의해 패딩되므로 버그를 이용하여 RAM을 읽어내려고 하면 세그먼트화 장애가 발생하여 프로그램이 종료됩니다.공격자가 카나리아가 어디에 있는지 알고 있거나 프로그램을 스택에서 읽을 수 있는 경우 카나리아를 읽을 수 있습니다.

랜덤 XOR 카나리아

랜덤 XOR 카나리아는 제어 데이터의 전부 또는 일부를 사용하여 XOR 스크램블된 랜덤 카나리아입니다.이와 같이 카나리아 또는 제어 데이터를 클로버하면 카나리아 값이 잘못됩니다.

랜덤 XOR 카나리아는 랜덤 카나리아와 같은 취약성을 가지고 있습니다.단, 카나리아를 취득하는 「스택에서 읽어내는」방법이 조금 더 복잡합니다.공격자는 보호를 스푸핑하는 데 필요한 원래 카나리아를 다시 생성하기 위해 카나리아, 알고리즘 및 제어 데이터를 가져와야 합니다.

또, 랜덤 XOR 카나리아는, 제어 데이터의 일부를 가리키도록 포인터를 변경하기 위해서, 구조내의 버퍼를 포인터로 오버플로 하는 것을 포함한 특정의 공격으로부터 보호할 수 있다.XOR 인코딩으로 인해 제어 데이터 또는 반환 값이 변경되면 canari가 잘못됩니다.포인터에 의해 카나리 위로 오버플로하지 않고 제어 데이터 또는 반환 값을 변경할 수 있습니다.

이러한 카나리아는 클로버된 포인터에 의해 제어 데이터가 변경되지 않도록 보호하지만 다른 데이터나 포인터 자체는 보호하지 않습니다.함수 포인터는 호출 시 에 오버플로우되어 셸 코드를 실행할 수 있기 때문에 특히 여기서 문제가 됩니다.

경계 검사

주요 기사: 경계 확인

경계 검사는 할당된 각 메모리 블록에 대해 런타임 경계 정보를 추가하고 런타임에 모든 포인터를 검사하는 컴파일러 기반 기술입니다.C 및 C++의 경우 포인터 계산[4] 시 또는 기준 해제 [5][6][7]시 경계 검사를 수행할 수 있습니다.

이 접근방식의 실장에서는 할당된 메모리의 [4][5][6]각 블록을 기술하는 중앙 저장소 또는 포인터와 포인터가 가리키는 영역을 기술하는 추가 데이터가 모두 포함된 [7]팻 포인터가 사용됩니다.

태그 부착

태그[8] 부착은 메모리 내의 데이터 유형에 태그를 붙이기 위한 컴파일러 기반 또는 하드웨어 기반(태그 부착 아키텍처 필요) 기술로 주로 유형 확인에 사용됩니다.메모리의 특정 영역을 실행 불가능으로 표시함으로써 데이터를 저장하기 위해 할당된 메모리가 실행 가능 코드를 포함하는 것을 효과적으로 방지할 수 있습니다.또, 메모리의 특정의 영역을 비할당이라고 마크 할 수 있기 때문에, 버퍼 오버플로우를 방지할 수 있습니다.

지금까지 태깅은 상위 수준의 [9]프로그래밍 언어를 구현하기 위해 사용되어 왔습니다.운영 체제의 적절한 지원을 받아 [10]태깅을 사용하여 버퍼 오버플로우를 검출할 수도 있습니다.예를 들어 Intel, AMD 및 ARM 프로세서에서 지원되는 NX 비트 하드웨어 기능이 있습니다.

실장

GNU 컴파일러 컬렉션(GCC)

스택스매싱 보호는 StackGuard에 의해 1997년에 처음 구현되어 1998년 USENIX [11]보안 심포지엄에서 발표되었습니다.StackGuard는 GCC 2.7의 Intel x86 백엔드에 대한 패치 세트로 도입되었습니다.StackGuard는 1998년부터 2003년까지 Immunix Linux 배포용으로 유지되었으며 터미네이터, 랜덤 및 랜덤 XOR 카나리 구현으로 확장되었습니다.StackGuard는 GCC 2003 서밋 [12]프로시저에서 GCC 3.x에 포함될 것을 제안받았으나 실현되지 않았습니다.

2001년부터 2005년까지 IBM은 ProPolice로 [13]알려진 스택 스매시 보호를 위한 GCC 패치를 개발했습니다.스택 프레임에서 로컬 포인터와 함수 인수 뒤에 버퍼를 배치함으로써 스택가드의 아이디어를 개선했습니다.이를 통해 포인터의 손상을 방지하고 임의 메모리 위치에 대한 액세스를 방지할 수 있습니다.

Red Hat 엔지니어는 ProPolice의 문제를 발견하고 2005년 GCC 4.1에 [14][15]포함시키기 위해 스택스매싱 보호를 다시 구현했습니다.이 작업에서는 일부 취약한 기능만 보호하는 플래그와 [16]필요 여부에 관계없이 모든 기능을 보호하는 플래그가 도입되었습니다.

2012년 구글 엔지니어들은 보안과 [17]성능의 균형을 맞추기 위해 이 깃발을 구현했다.이 플래그는 보다 많은 종류의 취약한 기능을 보호하지만 모든 기능은 보호하지 않으므로 보다 뛰어난 성능을 제공합니다.버전 4.[18]9 이후 GCC에서 사용할 수 있습니다.

모든 Fedora 패키지는 Fedora Core 5 이후 및 Fedora [19][20]20 이후로 컴파일됩니다.Ubuntu의 대부분의 패키지는 6.10 [21]이후 컴파일되어 있습니다.모든 Arch Linux 패키지는 [22]2011년부터 컴파일되었습니다.2014년 5월 4일 이후 빌드된 모든 Arch Linux 패키지는 [23]를 사용합니다.스택 보호는 Debian의 [24]일부 패키지와 [25]8.0 이후의 FreeBSD 기반 시스템에만 사용됩니다.스택 보호는 OpenBSD,[26] Hardened[27] Gentoo 및 DragonFly BSD를[citation needed] 포함한 특정 운영 체제에서 표준으로 제공됩니다.

StackGuard 및 ProPolice는 자동으로 할당된 구조에서 함수 포인터로 오버플로우가 발생하는 것을 방지할 수 없습니다.ProPolice는 적어도 이러한 구조를 함수 포인터보다 먼저 할당받도록 할당 순서를 재정렬합니다.포인터 보호를 위한 별도의 메커니즘이 PointGuard에서[28] 제안되었으며 Microsoft [29]Windows에서 사용할 수 있습니다.

Microsoft Visual Studio

Microsoft의 컴파일러 스위트는 2003년 이후를 통해 버퍼 오버플로우 보호를 구현하고 있습니다./[30]GS 명령줄 스위치.버전 2005부터 디폴트로 유효하게 되어 있습니다./GS-를 사용하면 보호가 비활성화됩니다.

IBM 컴파일러

스택 스매시 보호는 컴파일러 플래그를 사용하여 설정할 수 있습니다.-qstackprotect를 클릭합니다.[31]

쨍그랑/LLVM

Clang은 AddressSanitizer(-fsanitize=address),[6][32] -fsanitize=address 및 [33]SafeCode의 3가지 버퍼 오버플로 디텍터를 지원합니다.이러한 시스템은 성능 저하, 메모리 오버헤드 및 탐지된 버그 등급에 대해 서로 다른 트레이드오프를 가집니다.스택 보호는 OpenBSD를 [34]포함한 특정 운영 체제에서는 표준입니다.

인텔 컴파일러

인텔의 C/C++ 컴파일러는 GCC 및 Microsoft Visual [35]Studio와 유사한 옵션을 사용하여 스택스매싱 보호를 지원합니다.

페일 세이프 C

Fail-Safe[7] C는 오픈 소스 메모리 세이프 ANSI C 컴파일러로, 팻 포인터와 객체 지향 메모리액세스에 [36]근거해 경계 체크를 실행합니다.

Stack Ghost(하드웨어 기반)

Mike Frantzen에 의해 발명된 StackGhost는 레지스터 창의 스필/필 루틴에 대한 간단한 수정으로 버퍼 오버플로를 훨씬 더 이용하기 어렵게 만듭니다.Sun Microsystems SPARC 아키텍처의 고유한 하드웨어 기능(즉, 지연된 온스택 프레임 레지스터 창 스필/필)을 사용하여 리턴 포인터의 변경을 투과적으로 검출하여 이진수나 소스 수정 없이 모든 애플리케이션을 자동으로 보호합니다.퍼포먼스에 미치는 영향은 1% 미만으로 미미합니다.결과적으로 발생한 gdb 문제는 2년 후 Mark Kettenis에 의해 해결되어 이 기능을 사용할 수 있게 되었습니다.이 이벤트 이후에 StackGhost 코드가 OpenBSD/SPARC에 통합(및 최적화)되었습니다.

카나리아 예

x86 아키텍처 및 기타 유사한 아키텍처에 대한 일반 버퍼 할당은 버퍼 오버플로 엔트리에 표시됩니다.여기에서는 스택가드에 관련된 변경 프로세스를 보여 줍니다.

함수가 호출되면 스택프레임이 생성됩니다.스택 프레임은 메모리의 끝에서 선두까지 구축됩니다.각 스택프레임은 메모리의 선두에 가장 가까운 스택의 상단에 배치됩니다.따라서 스택 프레임 내의 데이터 끝에서 실행하면 이전에 스택프레임에 입력된 데이터가 변경되고 스택프레임 끝에서 실행하면 데이터가 이전 스택프레임에 배치됩니다.일반적인 스택 프레임은 다음과 같이 Return Address(RETA; 리턴 주소)가 첫 번째, 그 다음에 기타 Control Information(CTLI; 제어 정보)이 차례로 배치됩니다. 

(CTLI)(RETA)

C에서 함수는 많은 다른 콜 단위의 데이터 구조를 포함할 수 있습니다.호출 시 작성된 각 데이터는 스택프레임 내에 순서대로 배치되어 메모리의 끝에서 시작까지 순서가 매겨집니다.다음으로 가상의 함수와 그 스택프레임을 나타냅니다. 

인트 후우() {   인트 a;             /* 정수 */   인트 *b;            /* 정수 포인터 */   차 c[10];        /* 문자 배열 */   차 d[3];    b = &a;            /*를 초기화하여 a*/의 위치를 가리킵니다.   스트럭시(c,get_c()); /* 어딘가에서 c를 가져와 c*/에 씁니다.   *b = 5;            /* 메모리 b 지점의 데이터가 5 */로 설정되었음을 나타냅니다.   스트럭시(d,get_d());   돌아가다 *b;         /* 를 b 로부터 읽어, 발신자에게 전달합니다. } 
(d..) (c......) (b...)(a...)(CTLI)(RETA)

이 가상 상황에서는 어레이에 10바이트 이상 쓸 수 있습니다.c, 또는 문자 배열의 경우 13개 이상d초과분은 정수 포인터로 오버플로됩니다.b를 정수로 변환합니다.a를 제어정보에 입력해, 마지막으로 반환주소로 합니다.덮어쓰기b포인터는 메모리 내의 임의의 위치를 참조하도록 되어 있어 임의의 주소로부터 판독이 가능하게 됩니다.RETA를 덮어쓰면 함수는 (복귀를 시도할 때) 다른 코드, 즉 기존 함수(ret2libc) 또는 오버플로우 중에 스택에 기록된 코드를 실행하도록 할 수 있습니다.

한마디로 말하면, 부적절한 취급c그리고.d위의 무제한 strcpy() 호출과 같이 공격자가 할당된 값에 영향을 줌으로써 프로그램을 제어할 수 있습니다.c그리고.d직접적으로.버퍼 오버플로우 보호의 목적은 가능한 한 간섭이 적은 방법으로 이 문제를 검출하는 것입니다.이것은 해로울 수 있는 것을 제거하고 버퍼 뒤에 일종의 트립 와이어(카나리아)를 배치함으로써 이루어집니다.

버퍼 오버플로우 보호는 컴파일러의 변경으로 구현됩니다.이와 같이 보호는 스택 프레임상의 데이터 구조를 변경할 수 있다.이것은 ProPolice와 같은 시스템에서도 마찬가지입니다.위 함수의 자동 변수는 보다 안전하게 재배치됩니다. 배열c그리고.d스택 프레임에 최초로 할당되어 정수가 배치됩니다.a및 정수 포인터b기억 속에서 그들 앞에.스택 프레임이

(b) (a) (d) (c......) (CTLI)(RETA)

생성된 코드를 깨지 않고 CTLI 또는 RETA를 이동하는 것은 불가능하기 때문에 다른 방법을 사용한다.「카나리」(CNRY)라고 불리는 추가 정보는 스택프레임의 버퍼 뒤에 배치됩니다.버퍼가 오버플로하면 canari 값이 변경됩니다.따라서 프로그램을 효과적으로 공격하려면 공격자가 자신의 공격에 대한 명확한 징후를 남겨야 합니다.스택 프레임은

(b) (a) (d) (c......) (CNRY) (CTLI) (RETA)

모든 기능의 끝에는 RETA에 의해 나타나는 메모리 주소에서 실행을 계속하는 명령이 있습니다.이 명령을 실행하기 전에 CNRY를 체크하면 변경되지 않았는지 확인할 수 있습니다.CNRY 값이 테스트에 실패하면 프로그램 실행이 즉시 종료됩니다.본질적으로 의도적인 공격과 의도하지 않은 프로그래밍 버그가 모두 프로그램 중단을 초래합니다.

canari 기술은 모든 동적 버퍼 할당 직전 및 동적 버퍼 할당 해제 직후에 자동 배열을 사용하는 모든 함수 호출에 대해 몇 가지 오버헤드 명령을 추가합니다.이 기술로 발생하는 오버헤드는 크지 않습니다.하지만 카나리아가 변하지 않는 한 효과가 있다.공격자가 카나리아가 존재함을 알고 카나리아 값을 확인할 수 있다면 카나리아를 복사하기만 하면 됩니다.이것은 보통 의도적으로 조정하기 어렵고 의도하지 않은 상황에서는 가능성이 매우 낮습니다.

canary의 위치는 구현에 따라 다르지만 항상 버퍼와 보호된 데이터 사이에 있습니다.다양한 위치와 길이에 따라 다양한 이점이 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Fithen, William L.; Seacord, Robert (2007-03-27). "VT-MB. Violation of Memory Bounds". US CERT.
  2. ^ Levy, Elias (1996-11-08). "Smashing The Stack for Fun and Profit". Phrack. 7 (49): 14.
  3. ^ "Buffer Overflows: Attacks and Defenses for the Vulnerability of the Decade*" (PDF). Archived from the original (PDF) on 2013-03-09.
  4. ^ a b "Bounds Checking for C". Doc.ic.ac.uk. Archived from the original on 2016-03-26. Retrieved 2014-04-27.
  5. ^ a b "SAFECode: Secure Virtual Architecture". Sva.cs.illinois.edu. 2009-08-12. Retrieved 2014-04-27.
  6. ^ a b c "google/sanitizers". 19 June 2021.
  7. ^ a b c "Fail-Safe C: Top Page". Staff.aist.go.jp. 2013-05-07. Archived from the original on 2016-07-07. Retrieved 2014-04-27.
  8. ^ "Tuesday, April 05, 2005" (PDF). Feustel.us. Archived from the original (PDF) on June 23, 2016. Retrieved 2016-09-17.
  9. ^ Steenkiste, Peter; Hennessy, John (1987). "Tags and type checking in LISP: hardware and software approaches". ACM Sigops Operating Systems Review. ACM. 21 (4): 50–59. doi:10.1145/36204.36183.
  10. ^ "ClearPath Enterprise Servers MCP Security Overview" (PDF). Public.support.unisys.com. Archived from the original (PDF) on 2013-01-24. Retrieved 2014-04-27.
  11. ^ "Papers - 7th USENIX Security Symposium, 1998". Usenix.org. 2002-04-12. Retrieved 2014-04-27.
  12. ^ "Proceedings of the GCC Developers Summit" (PDF). May 2003. Archived from the original on 2004-07-15. Retrieved 2016-09-17.{{cite web}}: CS1 maint: bot: 원래 URL 상태를 알 수 없습니다(링크).
  13. ^ "GCC extension for protecting applications from stack-smashing attacks". Research.ibm.com. Retrieved 2014-04-27.
  14. ^ "GCC 4.1 Release Series — Changes, New Features, and Fixes - GNU Project - Free Software Foundation (FSF)". Gcc.gnu.org. Retrieved 2014-04-27.
  15. ^ "Richard Henderson - [rfc] reimplementation of ibm stack-smashing protector". Gcc.gnu.org. Retrieved 2014-04-27.
  16. ^ "Optimize Options - Using the GNU Compiler Collection (GCC)". Gcc.gnu.org. Retrieved 2014-04-27.
  17. ^ "Han Shen(ææ) - [PATCH] Add a new option "-fstack-protector-strong" (patch / doc inside)". Gcc.gnu.org. 2012-06-14. Retrieved 2014-04-27.
  18. ^ Edge, Jake (February 5, 2014). ""Strong" stack protection for GCC". Linux Weekly News. Retrieved 28 November 2014. It has made its way into GCC 4.9
  19. ^ "Security Features". FedoraProject. 2013-12-11. Retrieved 2014-04-27.
  20. ^ "#1128 (switching from "-fstack-protector" to "-fstack-protector-strong" in Fedora 20) – FESCo". Fedorahosted.org. Retrieved 2014-04-27.
  21. ^ "Security/Features - Ubuntu Wiki". Wiki.ubuntu.com. Retrieved 2014-04-27.
  22. ^ "FS#18864 : Consider enabling GCC's stack-smashing protection (ProPolice, SSP) for all packages". Bugs.archlinux.org. Retrieved 2014-04-27.
  23. ^ "svntogit/packages.git - Git clone of the 'packages' repository".
  24. ^ "Debian Security Hardening Statistics". Outflux.net. Retrieved 2014-04-27.
  25. ^ "FreeBSD 8.0-RELEASE Release Notes". Freebsd.org. 2013-11-13. Retrieved 2014-04-27.
  26. ^ "OpenBSD's gcc-local(1) manual page". gcc comes with the ProPolice stack protection extension, which is enabled by default.
  27. ^ "Hardened/Toolchain - Gentoo Wiki". 2016-07-31. The Gentoo hardened GCC switches on the stack protector by default unless explicitly requested not to.
  28. ^ "12th USENIX Security Symposium — Technical Paper".
  29. ^ "MSDN Blogs – Get the latest information, insights, announcements, and news from Microsoft experts and developers in the MSDN blogs".
  30. ^ "/GS (Buffer Security Check) (C++)". msdn.microsoft.com. Retrieved 2014-04-27.
  31. ^ "qstackprotect". Publib.boulder.ibm.com. Retrieved 2014-04-27.
  32. ^ "Clang Compiler User's Manual — Clang 3.5 documentation". Clang.llvm.org. Retrieved 2014-04-27.
  33. ^ "SAFECode". Safecode.cs.illinois.edu. Retrieved 2014-04-27.
  34. ^ "OpenBSD's clang-local(1) manual page". clang comes with stack protection enabled by default, equivalent to the -fstack-protector-strong option on other systems.
  35. ^ "User and Reference Guide for the Intel C++ Compiler 15.0: fstack-security-check, GS". software.intel.com. Retrieved 2015-02-13.
  36. ^ "thesis.dvi" (PDF). Staff.aist.go.jp. Retrieved 2016-09-17.

외부 링크