기본 콘텐츠로 건너뛰기

Secure-Coding-C-DCL-3

Secure-Coding-C-DCL-3

C 언어 시큐어코딩 - Declare and Initialization 3

상충되는 Linkage 식별자를 선언하지 않는다.

Linkage는 동일한 범위 내에서 여러 영역으로 선언되거나 여러 번 선언된 식별자를 동일한 개체나 함수를 참조하도록 만들 수 있다. 식별자는 externally linked, Internally linked 또는 not llinked로 분류된다. 이 세 종류의 분류는 다음과 같은 특징을 갖는다.
  • External linkage: 프로그램에 속한 모든 편집 단위 및 라이브러리에서 동일한 객체 또는 기능을 나타낸다. 식별자는 링커에서 사용할 수 있다. External
  • Internal linkage: 주어진 번역 단위 내에서 동일한 객체 또는 함수를 나타낸다. linker는 내부 링크가 있는 식별자에 대한 정보가 없다. 따라서 이러한 식별자는 번역 단위 내부에 있다.
  • No linkage: 식별자에 연결이 없는 경우 식별자를 사용하는 추가 선언은 새로운 변수 또는 새로운 유형과 같은 새로운 것을 선언한다.
한 번역 내에서 내부 및 외부 링크로 분류된 식별자의 사용은 정의되지 않은 동작이다. 번역의 단위는 헤더와 함께 소스 파일, 전처리 지시어를 통해 포함된 모든 소스 파일을 포함한다.
다음 표는 단일 변환 단위에서 두 번 선언된 객체에 할당된 연결을 나타낸다. 열은 첫 번째 선언, 행은 재 선언을 의미한다.
static (second) no linkage (second) extern (second)
static (first) internal Undefined Internal
no linkage (first) Undefined No linkage External
extern (first) Undefined Undefined External

잘못된 코드 예제

이 예제에서 i2i5는 내부와 외부 연결 모두 갖는 것으로 정의된다. 두 식별자 중 하나를 사용하면 정의되지 않은 동작이 발생하게 된다.
int i1 = 10;         /* Definition, external linkage */
static int i2 = 20;  /* Definition, internal linkage */
extern int i3 = 30;  /* Definition, external linkage */
int i4;              /* Tentative definition, external linkage */
static int i5;       /* Tentative definition, internal linkage */
 
int i1;  /* Valid tentative definition */
int i2;  /* Undefined, linkage disagreement with previous */
int i3;  /* Valid tentative definition */
int i4;  /* Valid tentative definition */
int i5;  /* Undefined, linkage disagreement with previous */
 
int main(void) {
  /* ... */
  return 0;
}

상세 정보

Microsoft Visual Studio 2013은 가장 높은 진단 수준에서도 이 코드에 대한 경고를 표시하지 않는다.
GCC 컴파일러는 i2i5의 충돌하는 정의에 치명적인 진단을 생성한다.

올바른 코드 예제

이 예제에서는 상충되는 정의가 존재하지 않는다.
int i1 = 10;         /* Definition, external linkage */
static int i2 = 20;  /* Definition, internal linkage */
extern int i3 = 30;  /* Definition, external linkage */
int i4;              /* Tentative definition, external linkage */
static int i5;       /* Tentative definition, internal linkage */
 
int main(void) {
  /* ... */
  return 0;
}

이 블로그의 인기 게시물

데일 카네기 인간관계론 정리

Remove-Server-Header

응답 메시지 내 서버 버전 정보 제거 1. Apache 1) 조치 방법 “/etc/htpd/conf/httpd.conf” 파일 안에서 1. ServerTokens OS → ServerTokens Prod 2. ServerSignature On → ServerSignature Off 로 변경한 후 아파치를 재시작하면 헤더 값의 아파치 버전 정보 및 OS 정보를 제거할 수 있다. 2) 참고 URL http://zetawiki.com/wiki/CentOS_ 아파치_보안권장설정_ServerTokens_Prod,_ServerSignature_Off 2. IIS 1) 조치 방법 IIS 6.0 urlscan_setup 실행. 설치. \windows\system32\inetsrv\urlscan\urlscan.ini 파일을 열어 다음 수정(RemoveServerHeader=0 을 RemoveServerHeader=1 로 변경) 서비스에서 IIS Admin Service 재시작. IIS 7.0 IIS 관리자를 열고 관리하려는 수준으로 이동합니다. 기능 보기에서 HTTP 응답 헤더를 두 번 클릭합니다. HTTP 응답 헤더 페이지에서 제거할 헤더를 선택합니다. 작업 창에서 제거를 클릭하고 예를 클릭합니다. 2) 참고 URL IIS 6.0 : http://gonnie.tistory.com/entry/iis6- 응답헤더-감추기 IIS 7.0 : https://technet.microsoft.com/ko-kr/library/cc733102(v=ws.10).aspx 3. jetty 1) 조치 방법 “jetty.xml” 파일에서 jetty.send.server.version=false 설정 2) 참고 URL http://attenuated-perspicacity.blogspot.kr/2009/09/jetty-61x-hardening.html 4. Nginx ...

CVE-2017-11352

CVE-2017-11352 ImageMagick 에서 발생했던 CVE-2017-9144 취약점의 미흡한 조치로 인하여 동일한 취약점이 다시 발생되었다. 재 발생된 취약점 CVE-2017-11352은 coders/rle.c 에서 RLE 이미지에 대한 부적절한 EOF 처리가 원인이었다. EOF 란? 파일의 끝(End of File, EOF)으로 데이터 소스로부터 더 이상 읽을 수 있는 데이터가 없음을 나타낸다. ImageMagick Github Page 에 들어가보면 해당 이슈를 상세히 확인할 수 있다. 부적절한 EOF 처리 원인은 소스 코드 수정 시 유사한 코드를 복사 붙여넣기 하는 과정에서 검증해야할 변수 명을 고치지 않고 그대로 적용해서 발생했다. operand=ReadBlobByte(image); if (opcode == EOF) ThrowRLEException(CorruptImageError, "UnexpectedEndOfFile" ); 이로 인해서 조치 완료된 줄 알았던 CVE-2017-9144 취약점은 CVE-2017-11352이라는 새로운 취약점 명으로 다시 조치 되었다. case SkipLinesOp: { operand=ReadBlobByte(image); - if (opcode == EOF) + if (operand == EOF) ThrowRLEException(CorruptImageError, "UnexpectedEndOfFile" ); if (opcode & 0x40 ) { operand=ReadBlobLSBSignedShort(image); - if (opcode == EOF) + if (operand == EO...