Null Dereference

프로그램이 null 포인터를 역참조할 가능성이 있기 때문에 NullException이 발생합니다.

Null 포인터 오류는 주로 프로그래머 가정을 하나 이상 위반한 결과로 발생합니다.

대부분의 null 포인터 문제는 일반적으로 소프트웨어 신뢰도 문제를 야기하지만 공격자가 의도적으로 null 포인터 역참조를 실행할 수 있는 경우 그 결과 발생하는 예외 사항을 사용하여 보안 로직을 무시하거나 차후의 공격을 계획하는 데 유용한 디버깅 정보를 응용 프로그램이 노출하도록 할 수 있습니다.

예제 1: 다음 코드에서 프로그래머는 시스템에 항상 “cmd”라는 속성이 정의되어 있다고 가정합니다. 공격자가 “cmd”가 정의되지 않도록 프로그램의 환경을 제어하게 되면 프로그램이 Trim() 메서드를 호출하려 할 때 null 포인터 예외 사항이 발생합니다.

string cmd = null;
...
cmd = Environment.GetEnvironmentVariable("cmd");
cmd = cmd.Trim();

프로그램이 null 포인터를 역참조할 가능성이 있기 때문에 조각화 오류가 발생합니다.

Null 포인터 예외는 일반적으로 하나 이상의 프로그래머 가정을 위반했을 때 발생합니다. 이 문제는 최소한 역참조 후 검사(check-after-dereference), 검사 후 역참조(dereference-after-check) 및 저장 후 역참조(dereference-after-store)라는 세 가지 문제를 유발합니다. 역참조 후 검사(check-after-dereference) 오류는 포인터가 null인지 검사하기 전에 null이 될 수 있는 포인터를 역참조할 경우 발생합니다. 검사 후 역참조(dereference-after-check) 오류는 프로그램이 null인지 여부를 명시적으로 검사하지만, null인 것으로 알려진 포인터를 역참조할 때 발생합니다. 이 유형의 오류는 철자 오류 또는 프로그래머의 실수로 발생합니다. 저장 후 역참조(dereference-after-store) 오류는 프로그램이 명시적으로 포인터를 null로 설정하고 이를 나중에 역참조할 경우에 발생합니다. 이 오류는 프로그래머가 선언된 상태의 변수를 null로 초기화하여 발생하는 경우가 많습니다.

대부분의 null 포인터 문제는 일반적인 소프트웨어 신뢰도 문제를 야기하지만 공격자가 의도적으로 null 포인터 역참조를 실행할 수 있는 경우 그 결과 발생하는 예외 사항을 활용함으로써 보안 로직을 무시하여 Denial Of Service(DoS) 공격을 가하거나 차후의 공격을 계획하는 데 유용한 디버깅 정보를 응용 프로그램이 노출하도록 할 수 있습니다.

예제 1: 다음 코드에서 프로그래머는 변수 ptr이 NULL이 아닌 것으로 가정합니다. 이 가정은 프로그래머가 포인터를 역참조하면 명시적인 것이 됩니다. 프로그래머가 NULL에 대해 ptr을 검사하면 이 가정이 반박됩니다. if문에서 검사할 때 ptr이 NULL이 되면 역참조될 때도 NULL이 되어 조각화 오류가 발생할 수 있습니다.

ptr->field = val;
...
if (ptr != NULL) {
	...
}

예제 2: 다음 코드에서 프로그래머는 변수 ptr이 NULL임을 확인한 다음 실수로 역참조합니다. if문에서 검사할 때 ptr이 NULL이면 null dereference가 발생하여 조각화 오류가 일어납니다.

if (ptr == null) {
        ptr->field = val;
        ...
}

예제 3: 다음 코드에서 프로그래머는 '\0' 문자열이 실제로 0 또는 NULL인 것을 잊고 null 포인터를 역참조하여 조각화 오류가 일어납니다.

if (ptr == '\0') {
        *ptr = val;
        ...
}

예제 4: 다음 코드에서 프로그래머는 명시적으로 변수 ptr를 NULL로 설정합니다. 나중에 프로그래머는 개체의 null 값을 검사하기 전에 ptr를 역참조합니다.

*ptr = NULL;
...
ptr->field = val;
...
}