gcc -D_FORTIFY_SOURCE = 1과 -D_FORTIFY_SOURCE = 2의 차이

gcc -D_FORTIFY_SOURCE = 1과 -D_FORTIFY_SOURCE = 2의 차이

---

누군가 gcc -D_FORTIFY_SOURCE=1와 의 차이점을 지적 할 수 있습니까 -D_FORTIFY_SOURCE=2? =2더 안전한 것 같아요 ? 점별로 차이점을 나열하는 목록을 찾을 수 없었습니다.

-D_FORTIFY_SOURCE=2와 함께 사용해야 하는 것도 읽었습니다 -O2. 그렇지 않으면 모든 기능을 사용할 수 없습니다. 또한 여기에서는 회귀를 자세히 지정하는 목록을 찾지 못했습니다. 특히 -Os타겟이 플래시 메모리가 많지 않은 장치이므로 컴파일하는 데 관심이 있습니다 .

이것이 문서화 된 위치에 대한 모든 힌트를 환영합니다!

---

기능 테스트 매크로 ( man 7 feature_test_macros) 의 매뉴얼 페이지에서

_FORTIFY_SOURCE (glibc 2.3.4 이후)

일부 경량 확인이 매크로 발생 정의하는 (예를 들어, 다양한 캐릭터 메모리 조작 함수를 이용하는 경우 어떤 버퍼 오버 플로우 에러를 검출하도록 수행되는 memcpy, memset, stpcpy, strcpy, strncpy, strcat, strncat, sprintf, snprintf, vsprintf, vsnprintf, gets, 및 다양한 문자 변형체). 일부 함수의 경우 인수 일관성이 확인됩니다. 예를 들어, 지정된 플래그가를 포함 할 때 mode 인수 open와 함께 제공된 검사가 수행 됩니다 . 모든 문제가 감지되는 것은 아니며 몇 가지 일반적인 경우입니다.O_CREAT

_FORTIFY_SOURCE컴파일러 최적화 수준 1 ( gcc -O1) 이상에서가 1로 설정 되면 준수 프로그램의 동작을 변경하지 않아야하는 검사가 수행됩니다.

으로 _FORTIFY_SOURCE2로 설정, 좀 더 검사가 추가되지만 일부 부합하는 프로그램이 실패 할 수 있습니다.

일부 검사는 컴파일시 (헤더 파일에 구현 된 매크로 논리를 통해) 수행 될 수 있으며 컴파일러 경고가 발생합니다. 다른 검사는 런타임에 수행되며 검사에 실패하면 런타임 오류가 발생합니다.

이 매크로를 사용하려면 gcc버전 4.0부터 사용할 수있는 컴파일러 지원이 필요합니다 .

또한 FORTIFY_SOURCE로 애플리케이션 보안 강화 (2014 년 3 월) 기사에서는 다음 과 같이 설명합니다.

• gcc -D_FORTIFY_SOURCE=1컴파일 타임에만 검사를 추가합니다 (일부 헤더는으로 필요 #include <string.h>).
• gcc -D_FORTIFY_SOURCE=2 또한 런타임에 검사를 추가합니다 (버퍼 오버플로가 감지되면 프로그램이 종료 됨)

기본적으로 _FORTIFY_SOURCE레벨 2는 더 안전하지만 약간 더 위험한 컴파일 전략입니다. 이를 사용하는 경우 컴파일 된 코드에 대해 매우 강력한 회귀 테스트를 통해 컴파일러가 예기치 않은 동작을 도입하지 않았 음을 증명해야합니다.

---

http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html 은 feature_test_macros(7).

명확성을 위해 가볍게 편집 / 재 포맷 된 관련 발췌 내용은 다음과 같습니다.

차이 -D_FORTIFY_SOURCE=1와 -D_FORTIFY_SOURCE=2위한 예이며

  struct S {
      struct T {
        char buf[5];
        int x;
      } t;
      char buf[20];
  } var;

와 함께 -D_FORTIFY_SOURCE=1,

  strcpy (&var.t.buf[1], "abcdefg");

오버플로 (객체는 전체 VAR)로 간주되지 않지만-D_FORTIFY_SOURCE=2

  strcpy (&var.t.buf[1], "abcdefg");

버퍼 오버 플로우로 간주됩니다.

또 다른 차이점은 함께 있다는 것입니다 -D_FORTIFY_SOURCE=2, %n가장 일반적인 형식 문자열에 *printf(일반적으로 문자열 리터럴 가족 기능에만 허용이 읽기 전용 메모리에 저장되어있는 경우 gettext의 _("%s string %n")도 괜찮습니다)하지만, 일반적으로 공격자의 시도는 형식 문자열을 악용하는 경우 취약점 %n은 공격자가 쓸 수있는 곳입니다.

참고 URL : https://stackoverflow.com/questions/13517526/difference-between-gcc-d-fortify-source-1-and-d-fortify-source-2