메모리 주소에서 free()를 두 번 이상 인수로서 호출하면 Double free 오류가 발생합니다.



동일한 값에 대해 free()를 두 번 호출하면 buffer overflow가 발생할 수 있습니다. 프로그램이 같은 인수로 free()를 두 번 호출하면 프로그램의 메모리 관리 데이터 구조가 손상됩니다. 이 손상으로 인해 프로그램이 손상되거나 경우에 따라 이후에 있을 두 번의 malloc() 호출이 같은 포인터를 반환하기도 합니다. malloc()이 같은 값을 두 번 반환하고 나중에 프로그램이 이 중복 할당된 메모리에 작성되는 데이터에 대한 제어권을 공격자에게 넘겨주면 프로그램은 buffer overflow 공격에 취약해집니다.

예제 1: 다음 코드는 double free 취약점의 간단한 예를 보여 줍니다.

	char* ptr = (char*)malloc (SIZE);
	...
	if (abrt) {
	  free(ptr);
	}
	...
	free(ptr);

Double free 취약점에는 다음의 두 가지 일반적인(때로는 겹치기도 하는) 원인이 있습니다.

- 오류 조건 및 기타 예외 상황.

- 프로그램의 어떤 부분이 메모리 해제를 담당하고 있는지에 대한 혼란.

일부 double free 취약점은 앞의 예제보다 크게 복잡하지 않지만 대부분은 수백 줄의 코드 또는 다른 파일에까지 흩어져 있습니다. 프로그래머는 특히 전역 변수를 두 번 이상 해제하는 실수를 자주 범하는 것 같습니다.

유니코드 양방향 재정의 제어 문자가 포함된 소스 코드는 내부자 위협 공격의 신호일 수 있습니다. 이러한 공격은 C, C++, C#, Go, Java, JavaScript, Python 및 Rust와 같은 프로그래밍 언어의 공급망을 통해 활용될 수 있습니다. Nicholas Boucher와 Ross Anderson은 여러 변종 공격을 이미 발표했으며 여기에는 Early Returns, Commenting-Out 및 Stretched Strings 등이 포함됩니다.
예제 1: 다음 코드는 C 소스 코드 파일에서 Early Return 공격으로 이어지는 제어 문자를 보여줍니다.

#include <stdio.h>

int main() {
	/* Nothing to see here; newline RLI /*/ return 0 ;
	printf("Do we get here?\n");
	return 0;
}

Example 1의 RLI(오른쪽에서 왼쪽으로 격리) 유니코드 양방향 제어 문자는 코드를 다음과 같이 보이게 합니다.

#include <stdio.h>

int main() {
	/* Nothing to see here; newline; return 0 /*/
	printf("Do we get here?\n");
	return 0;
}

특히 주의할 점은 취약한 편집기/뷰어에서 코드 검토를 수행하는 개발자는 취약한 컴파일러가 처리하는 것을 눈으로 볼 수 없다는 것입니다. 특히 프로그램 흐름을 수정하는 조기 반환 문이 여기에 해당합니다.

이 라이브러리는 실험적 라이브러리로 간주되므로 분명한 이유가 없는 한 운영 환경에서 사용하지 않아야 합니다.

Buffer overflow는 가장 널리 알려진 형태의 소프트웨어 보안 취약점입니다. 대부분의 소프트웨어 개발자가 buffer overflow의 취약점이 무엇인지 알고 있지만 이전 응용 프로그램 및 새로 개발된 응용 프로그램 모두에 대한 buffer overflow 공격은 여전히 빈번하게 발생합니다. 문제의 일부는 Buffer overflow가 발생하는 다양한 방식 때문이고 일부는 이 취약점을 예방하는 데 사용하는, 오류가 발생하기 쉬운 기법 때문입니다.

전형적인 Buffer overflow 익스플로이트에서 공격자는 프로그램에 데이터를 보내고 프로그램은 크기가 작은 스택 버퍼에 데이터를 저장합니다. 그 결과, 함수의 반환 포인터를 비롯한 호출 스택에 있는 정보를 덮어씁니다. 데이터는 함수가 값을 반환할 때 공격자의 데이터에 들어 있는 악성 코드에 제어를 전달하도록 반환 포인터 값을 설정합니다.

이런 유형의 스택 buffer overflow가 일부 플랫폼 및 일부 개발 커뮤니티에서는 여전히 빈번하지만 대표적으로 힙 buffer overflow 및 off-by-one 오류를 포함하여 다른 유형의 buffer overflow 도 많이 있습니다. Building Secure Software[1], Writing Secure Code[2] 및 The Shellcoder's Handbook[3]을 비롯하여 buffer overflow 공격의 동작 원리를 자세하게 기술한 훌륭한 책들이 많이 있습니다.

코드 수준에서 buffer overflow의 취약점은 일반적으로 프로그래머의 가정 위반과 관련이 있습니다. C 및 C++의 많은 메모리 조작 함수는 범위 검사를 수행하지 않으며 자신이 동작을 수행하는 버퍼의 할당 범위를 쉽게 침범합니다. strncpy()와 같은 범위 지정 함수도 잘못 사용되면 취약점을 일으킬 수 있습니다. 대부분의 buffer overflow의 원인은 메모리 조작과 데이터의 크기 또는 구성에 대한 가정 위반이 결합된 것입니다.

이 경우 부적절하게 생성된 format string으로 인해 프로그램이 할당된 메모리 경계 외부에 있는 값에 접근할 수 있습니다.

예제: 다음은 포맷 지정자의 수가 함수에 전달된 인수의 수와 일치하지 않으므로 스택에서 임의의 값을 읽습니다.

void wrongNumberArgs(char *s, float f, int d) {
   char buf[1024];
   sprintf(buf, "Wrong number of %.512s");
}

Buffer overflow는 가장 널리 알려진 형태의 소프트웨어 보안 취약점입니다. 대부분의 소프트웨어 개발자가 buffer overflow의 취약점이 무엇인지 알고 있지만 이전 응용 프로그램 및 새로 개발된 응용 프로그램 모두에 대한 buffer overflow 공격은 여전히 빈번하게 발생합니다. 문제의 일부는 Buffer overflow가 발생하는 다양한 방식 때문이고 일부는 이 취약점을 예방하는 데 사용하는, 오류가 발생하기 쉬운 기법 때문입니다.

전형적인 Buffer overflow 익스플로이트에서 공격자는 프로그램에 데이터를 보내고 프로그램은 크기가 작은 스택 버퍼에 데이터를 저장합니다. 그 결과, 함수의 반환 포인터를 비롯한 호출 스택에 있는 정보를 덮어씁니다. 데이터는 함수가 값을 반환할 때 공격자의 데이터에 들어 있는 악성 코드에 제어를 전달하도록 반환 포인터 값을 설정합니다.

이런 유형의 스택 buffer overflow가 일부 플랫폼 및 일부 개발 커뮤니티에서는 여전히 빈번하지만 대표적으로 힙 buffer overflow 및 off-by-one 오류를 포함하여 다른 유형의 buffer overflow 도 많이 있습니다. Building Secure Software[1], Writing Secure Code[2] 및 The Shellcoder's Handbook[3]을 비롯하여 buffer overflow 공격의 동작 원리를 자세하게 기술한 훌륭한 책들이 많이 있습니다.

코드 수준에서 buffer overflow의 취약점은 일반적으로 프로그래머의 가정 위반과 관련이 있습니다. C 및 C++의 많은 메모리 조작 함수는 범위 검사를 수행하지 않으며 자신이 동작을 수행하는 버퍼의 할당 범위를 쉽게 침범합니다. strncpy()와 같은 범위 지정 함수도 잘못 사용되면 취약점을 일으킬 수 있습니다. 대부분의 buffer overflow의 원인은 메모리 조작과 데이터의 크기 또는 구성에 대한 가정 위반이 결합된 것입니다.

이 경우 부적절하게 생성된 format string으로 인해 프로그램이 데이터 값을 잘못 변환하거나 할당된 메모리 경계 외부에 있는 값에 접근할 수 있습니다.

예제: 다음 코드는 %d 포맷 지정자를 사용하여 float에서 f를 잘못 변환합니다.

void ArgTypeMismatch(float f, int d, char *s, wchar *ws) {
   char buf[1024];
   sprintf(buf, "Wrong type of %d", f);
   ...
}

내부 Intent는 내부 구성 요소에서 정의한 대로 사용자 지정 작업을 사용합니다. 암시적 Intent는 특정 구성 요소에 대한 지식 없이도 임의의 외부 구성 요소에서 Intent 호출을 용이하게 할 수 있습니다. 이 두 가지를 결합하면 응용 프로그램이 원하는 응용 프로그램 컨텍스트 외부에서 특정 내부 사용을 위해 지정된 Intent에 액세스할 수 있습니다.

외부 응용 프로그램에서 내부 Intent를 처리하는 기능을 사용하면 심각도에 따라 Intent에 지정된 내부 작업의 용량에 따라 정보 유출 및 서비스 거부부터 원격 코드 실행까지 다양한 MiTM(Man-in-The-Middle) 공격이 가능해집니다.

예제 1: 다음 코드는 암시적 내부 Intent를 사용합니다.

...
val imp_internal_intent_action = Intent("INTERNAL_ACTION_HERE")
startActivity(imp_internal_intent_action)
...

Android Intent는 임의 구성 요소가 수행하는 작업에 대한 명령을 제공하여 응용 프로그램과 응용 프로그램 구성 요소를 함께 바인딩하는 데 사용됩니다. 나중에 Intent를 전달하기 위해 PendingIntent가 생성됩니다. 암시적 Intent는 일반 이름과 필터를 사용하여 실행을 결정함으로써 임의의 외부 구성 요소에서 Intent 호출을 용이하게 합니다.

암시적 Intent가 PendingIntent로 생성되는 경우 이로 인해 Intent가 의도한 임시 컨텍스트의 외부에서 실행되는 의도하지 않은 구성 요소로 전송되어 시스템이 서비스 거부, 개인 정보 및 시스템 정보 유출, 권한 에스컬레이션과 같은 악의적 공격에 취약해질 수 있습니다.

예제 1: 다음 코드는 암시적 PendingIntent를 사용합니다.

...
val imp_intent = Intent()
val flag_mut = PendingIntent.FLAG_MUTABLE
val pi_flagmutable_impintintent = PendingIntent.getService(
    this,
    0,
    imp_intent,
    flag_mut
)
...