기본 콘텐츠로 건너뛰기

Unsigned-Numeric-overflow

Unsigned-Numeric-overflow

부호 없는 정수 경계

오버플로우

정수 오버플로우 예

u_char *make_table(unsigned int width, unsigned int height, u_char *init_row)
{
	unsigned int n;
	int i;
	u_char *buf;

	n = width * height;
	buf = (char *)malloc(n);
	if (!buf)
		return (NULL);

	for (i = 0; i < height; i++)
		memcpy(&buf[i*width], init_row, width);

	return buf;
}

make_table() 함수의 목적은 너비와 높이, 초기 배열을 받아들여 각 행이 init_row 값과 동일한 값으로 초기화된 테이블을 메모리에 생성하는 것이다. 만약 사용자에게 widthheight에 대한 제어권을 갖고 있다면 오버플로우 공격을 일으킬 가능성이 있다.

너비가 1,000,000이고 높이가 3,000 같은 큰 값을 지정한다면 malloc()함수를 호출하여 3,000,000,000 바이트를 할당하는 과정에서 에러를 감지하고 실패할 확률이 높다. 하지만 결과 값에서 1 비트만 큰 산술 오버플로우를 유도한다면 성공할 가능성이 높다. 실제 초기화는 for루프에서 이루어지기 때문이다.

사용자가 width를 0x400으로, height를 0x1000001로 할당한다면 곱셈 결과 0x400000400이며, 이 값의 모듈로 0x100000000은 0x00000400 또는 1024가 된다. 그러므로 1024바이트가 할당되고 for루프에서 init_row를 약 천육백만 번 정도 더 많이 복사하게 된다.

OpenSSH 시도 응답 정수 오버플로우 예

이 예제는 OpenSSH 실제 코드에서 발생한 취약점으로 auth2-chall.c의 input_userauth_info_response()함수에 있는 시도 응답 인증 코드이다.

u_int nresp;
...
nresp = packet_get_int();
if (nresp > 0) {
	response = xmalloc(nresp * sizeof(char*));
	for (i = 0; i < nresp; i++)
		response[i] = packet_get_string(NULL);
}
packet_check_eom();

사용자가 제어할 수 있는 부호 없는 정수 변수 nresp는 얼마나 많은 응답을 기대하는지 서버에게 알려주기 위해 사용된다. uresp 값을 이용해 response[] 배열을 할당하고 네트워크 데이터를 채운다. xmalloc() 호출을 이용해 response[] 배열을 할당할 때 nresp는 보통 4 바이트인 sizeof(char *) 값을 곱한다. 사용자가 nresp 값을 충분히 큰 값으로 설정한다면 정수 오버플로우가 발생할 수 있다.

예를 들어 nresp가 0x40000020라면 여기에 4를 곱한 값은 0x80이 된다. 그러므로 0x80바이트가 할당되고 뒤의 for루프는 이 패킷에서 0x40000020 문자열을 가져오려고 한다.

언더플로우

Unsigned integer 언더플로우 예

struct header {
	unsigned int length;
	unsigned int message_type;
};

char *read_packet(int sockfd)
{
	int n;
	unsigned int length;
	struct header hdr;
	static char buffer[1024];

	if(full_read(sockfd, (void *)&hdr, sizeof(hdf)) <= 0) {
		error("full_read: %m");
		return NULL;
	}

	legnth = ntohl(hdr.length);

	if(length > (1024 + sizeof(struct header) - 1)) {
		error("not enough room in buffer\n");
		return NULL;
	}

	if(full_read(sockfd, buffer, length - sizeof(struct header)) <= 0) {
		error("read: %m");
		return NULL;
	}
	
	buffer[sizeof(buffer) - 1] = '\0';

	return strdup(buffer);
}

이 코드는 네트워크에서 패킷 헤더를 읽어 들여 32비트 필드를 length 변수에 저장한다. length변수는 패킷의 전체 바이트의 숫자이며, 프로그램은 오버플로우를 방지하기 위해 먼저 패킷의 데이터 부분이 1024보다 길지 않는지 검사한다. 그런 다음 (length - sizeof(struct header)) 바이트를 버퍼에 읽음으로써 네트워크에서 패킷의 나머지를 읽어 들이려고 한다.

취약점은 바로 사용자가 sizeof(struct header)보다 작은 length를 제공할 때 발생된다. 이때 (length - sizeof(struct header))에서 정수 언더플로루악 발생하고 full_read()에 굉장히 큰 size 값을 매개변수로 넘기게 된다.

이 에러는 커넥션이 종료될 때까지 read()가 데이터를 버퍼에 복사하는 지점에서 버퍼 오버플로우를 발생시키고, 이로 인해 공격자가 프로세스 제어를 넘겨주게 된다.

이 블로그의 인기 게시물

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

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...