cwe119 버퍼 오버플로우 방어

cwe 119

메모리 버퍼의 경계가 있는데 경계와 관련된 연산에 대한 제한, 제약을 적절히 처리하지 못할때 생길 수 있는 약점

어떤 소프트웨어는 메모리 버퍼와 관련된 연산을 할 수 있다.

하지만 그 연산은 버퍼의 의도된 경계 바깥쪽의 영역을 read/wrtie할 수 있음

연산의 제약조건은 버퍼의 의도된 경계내에서 연산해야

버퍼의 경계내의 메모리를 읽고 쓰기 해야됨

 

어떤 언어는 직접적으로 메모리 위치를 참조하는데 그 위치가 실제로 유효한지 아닌지 확인 하지 않음

프로그램이 참조할 수 있는 유효한 주소인지 체크하지 않아 다른 변수나 자료구조 내부 프로그램 메모리 영역을 읽거나 쓸 수 있음 = >연산 제약을 제대로 처리 하지 않았기 때문에

공격으로 연결되면 임의의 코드를 실행할 수 있고 임의의 제어흐름으로 변조, 민감한 정보 읽기, 시스템이 망가짐

 

cwe 119 = > 버퍼 오버플로우라고도 함

버퍼 오버플로우는 사람마다 다른 의미로 사용가능

어떤 도구는 버퍼의끝을 넘어서서 write하는것

다른 개발자는 버퍼의 경계밖(버퍼의 시작점, 끝 밖의 공간)에서 읽거나 쓰는것.

또 어떤 사람들은 버퍼의 끝 이후에 어떠한 행동을 하는 것(읽기, 쓰기 가능)

사람마다 다르기때문에 혼란스러운 용어임

 

따라서 메모리 경계에서 부적절한 연산 제한이 올바른 표현이다.'

 

이러한 약점의 결과는 CIA가 깨짐

인가되지 않은 코드,명령실행, 메모리 변조 가능

한바이트만 조작할 수 있음

 

가용성, 기밀성

어떤 메모리를 읽을수 잇고 시스템이 비정상적으로 종료될수 잇음 (dos) cpu같은 자원을 소모(메모리도 가능)

메모리 경계를 넘어서면 메모리의 붕괴를 가져와 시스템이 붕괴됨

해당 프로그램이 공격을 받아서 무한루프상태로 갈수도 있다.

 

기밀성

read memory

주어진 자료구조 범위를 넘어서서 읽으면 민감한 정보를 읽을 수도 잇다.

메모리의 현재 버퍼의 위치와 같은 정보

 

어떻게 완화??

소프트웨어 보안은 개발생명 전 주기에서 고려

각 단계에서 취약점을 완화할 숭 ㅣㅆ다

요구사항분석 => 언어선택을 잘 해야. cwe119에 강한 언어를 사용하며 ㄴ좋다, c보단 자바와 같은 언어(자체적으로 메모리 관리를 함) ada나 c#은 오버플로우 보호기법을 적용하고 잇음

그렇지만 이러한 언어들은 binary가 아님 실제 실행시 native코드로 변환 되어야함. 따라서 native code와 상호작용하는 인터페이스는 오버플로우 약점에 취약(자바 가상머신은 c로 만들어져잇음)

언어를 윗단에서 좋은 언어를 사용하더라도 완전하게 해결하는 것은 아님

 

아키텍쳐및 설계

라이브러리나 프레임워크를 잘 사용

검증이된 라이브러리나 프레임 워크 사용 => safe c String 라이브러리, strsafe.h

string 관련 오버플로우 문제를 해결 => 완벽X 

많은 오버플로우는 string고 ㅏ연관 없음, 하지만 string관련 문제를 해결가능

cwe119취약점을 방어할 숭 ㅣㅆ다.

 

빌드 컴파일 단계

컴파일 할때 최신 컴파일러사용, 컴파일 옵션을 버퍼 오버플로우를 탐지할 수 잇게 사용

MS visual studio 에선 GS flag, Fedora/red hat에선 fortify source gcc flag사용 

공격이나 취약점을 조기에 탐지할 숭 ㅣㅆ음

하지만 완변하지 ㄴ않음

 

 

구현단계 

자신이 작성중인 버퍼가 원하는 대로 작동하는지 두번이상 확인

strcpy -> strncpy

gets->fgets

memcpy보다 안전한 것 사용

안전한 라이브러리 함수 사용

 

운영단계

운영 환경을 좀더 안전하게 만들어라

관리자는 aslr , position-independent executable (pie)와 같은 기능을 사용해서 특정한 주소를 공격자가 예측하지 못하게 해라

공격자는 버퍼의 주소를 예측하기 어려움

NX비트 활용 (hw기법)

임의의 코드가 스택이나 데이터 세그먼트에 들어갈 확률이 높은데,  data execution protection(nx) 를 하면 코드 세그먼트가 아닌 스택이나 데이터 세그먼트 코드는 실행하기 못하게함.기본적으로 프로세스의 메모리 레이아웃에서는 코드, 텍스트 세그먼트의 코드만 실행해야함. 공격자들은 자기가 실행하고 싶은 코드를 스택이나 ㄴ=데이터 세그먼트에 넣음, 

기본적으로 코드(텍스트) 세그먼트는 read only 여서 코드 주입 불가