DLL 개발자가 주의해야 할 Secure CRT 함수 사용
C/C++에서 고질적으로 자주 나타나는 버퍼 오버런(buffer overflow, buffer overrun) 문제를 (해결이 아닌) 완화시키기 위해 마이크로소프트는 기존 CRT 함수에 _s 접미사를 붙인 SecureCRT를 내놓게 됩니다.
Security Features in the CRT
; https://learn.microsoft.com/en-us/cpp/c-runtime-library/security-features-in-the-crt
Security-Enhanced Versions of CRT Functions
; https://learn.microsoft.com/en-us/cpp/c-runtime-library/security-enhanced-versions-of-crt-functions
SecureCRT Sample: Converting Deprecated CRT Functions to their _s Counterparts?
- Visual Studio 2005 Retired documentation
; https://msdn.microsoft.com/en-us/library/zdktx3ts(v=vs.80).aspx
; https://www.microsoft.com/en-us/download/details.aspx?id=55984
가령, 다음과 같이 len = 3인 버퍼에 그 길이를 넘는 문자열을 복사할 수 있는데,
void main()
{
wchar_t buf[3];
wcscpy(buf, L"test");
}
그럼, buf 저장소에 다음과 같은 내용으로 10 바이트가 무조건 채워지게 됩니다.
sizeof(wchar_t) * 4 + 2byte null
당연히 buf가 보장하는 메모리 영역은 6바이트인데 10바이트가 써졌으니 나머지 4바이트는 다른 영역의 값을 덮어쓰게 되고 운이 나쁘다면 프로그램은 비정상 종료하게 됩니다. 게다가 어떤 메모리를 덮어썼냐에 따라 디버깅도 매우 힘들어질 수 있는데, 경험 많은 Native 개발자에게도 이런 유의 디버깅은 가능한 피하고 싶은 문제 중의 하나입니다. (반대로, 이런 문제를 디버깅했을 때의 짜릿함도 있겠지만! ^^;)
마이크로소프트의 경우, 위와 같은 상황에서의 문제 해결을 쉽게 하기 위해 "Debug" 모드로 컴파일하는 경우 (/GS 옵션이 적용되면) 일부러 __security_cookie 값을 변수의 메모리 부근에 보관해 둔 후 CRT 함수 호출 후 버퍼 오버플로우로 인해 __security_cookie 값이 깨졌는지를 확인하는 "__RTC_CheckEsp" 함수 호출 코드를 넣어둡니다. 따라서, Visual Studio에서 Debug 모드로 위의 프로그램을 실행한 경우 다음과 같은 오류 창이 발생합니다.
Debug Error!
Program: ...\ConsoleApplication1\Debug\ConsoleApplication1.exe
Module: ...\ConsoleApplication1\Debug\ConsoleApplication1.exe
File:
Run-Time Check Failure #2 - Stack around the variable 'buf' was corrupted.
(Press Retry to debug the application)
반면, Release 모드로 빌드하고 실행하면 __security_cookie + __RTC_CheckEsp 코드가 없어지므로 이제부터는 확률적으로 프로그램 상황에 따라 문제가 발생 또는 그냥 지나갈 수 있습니다.
이런저런 문제로 인해 마이크로소프트는 컴파일 단계에서부터 SecureCRT 함수를 사용하라고 권장하는 경고를 띄우게 됩니다.
1>c:\consoleapplication1\consoleapplication1.cpp(12): warning C4996: 'wcscpy': This function or variable may be unsafe. Consider using wcscpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
1> c:\program files (x86)\windows kits\10\include\10.0.10240.0\ucrt\corecrt_wstring.h(121): note: see declaration of 'wcscpy'
그래서 처음의 코드를 다음과 같이 바꿔줄 수 있습니다.
void main()
{
wchar_t buf[3];
wcscpy_s(buf, 3, L"test"); // buf의 크기가 최대 3임을 wcscpy_s 함수에 전달.
}
따라서 wcscpy_s 함수는 문자열을 복사하면서 두 번째 인자로 전달된 크기를 벗어났는지의 여부를 체크할 수 있습니다. 만약 벗어나게 되면, 응용 프로그램을 강제 종료합니다.
문제는, 이것이 Debug/Release 모드에 상관없이 강제 종료된다는 점이고 3rd-party DLL 개발자는 이런 상황을 특히 주의해야 합니다.
예를 들어, 파일 업로드 기능의 DLL이 IIS 웹 서버 프로세스(w3wp.exe)에서 동작 중일 때 클라이언트로부터 전달되는 파일명을 복사하는 함수를 다음과 같이 작성했다고 가정해 보겠습니다.
wchar_t buf[MAX_PATH];
wcscpy_s(buf, MAX_PATH, web_browser_passed_file_name);
아마도 평상시에는 (파일 명이 260바이트 이상인 경우는 거의 없을 테니) 위의 문제가 별다르게 나타나지 않을 수 있습니다. 하지만, 누군가 악의적인 의도를 가진 사용자가 일부러 260바이트가 넘는 함수명을 전달하는 경우 위의 코드 실행으로 인해 프로세스(w3wp.exe)가 강제 종료하게 됩니다. 차라리 파일 업로드 기능이 실패하는 것이 낫지, w3wp.exe를 비정상 종료시켜 버리는 것은 분명 문제가 있습니다.
이에 대한 우회 법으로 _set_invalid_parameter_handler를 이용해,
Parameter Validation
; https://learn.microsoft.com/en-us/cpp/c-runtime-library/parameter-validation
_set_invalid_parameter_handler, _set_thread_local_invalid_parameter_handler
; https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/set-invalid-parameter-handler-set-thread-local-invalid-parameter-handler
인자가 유효하지 않은 경우 비정상 종료하지 않도록 할 수 있습니다.
void myInvalidParameterHandler(const wchar_t* expression,
const wchar_t* function, const wchar_t* file, unsigned int line, uintptr_t pReserved)
{
// abort(); // 주석을 해제하면 Release 모드에서도 비정상 종료
}
void main()
{
wchar_t buf[3];
_invalid_parameter_handler oldHandler;
oldHandler = _set_invalid_parameter_handler(myInvalidParameterHandler);
errno_t ret = wcscpy_s(buf, 3, L"test");
if (EINVAL == ret || ERANGE == ret)
{ // 예제 코드의 경우 버퍼가 작으므로 ERANGE(34) 반환
cout << ret << endl;
}
_set_invalid_parameter_handler(oldHandler);
}
물론, _set_invalid_parameter_handler를 사용해도 Debug 모드에서는 비정상 종료를 하지만, 대신 다음과 같이 친절한 오류 메시지를 보고해 줍니다.
Debug Assertion Failed!
Program: ...\ConsoleApplication1\Debug\ConsoleApplication1.exe
File: minkernel\crts\ucrt\inc\corecrt_internal_string_templates.h
Line: 81
Expression: (L"Buffer is too small" && 0)
For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.
(Press Retry to debug the application)
그런데, 3rd-party DLL 개발자가 _set_invalid_parameter_handler를 사용해 전역적으로 오류를 막아낸다는 것이 또 그다지 바람직하지는 않습니다. 그렇다고 저렇게 SecureCRT 함수를 사용하는 곳마다 잠깐씩 handler를 설정하는 것도 무리일 듯싶으니, 이런 경우에는 오류가 발생하지 않는 버전을 사용하는 것이 좋습니다. 예전에 설명했던 _TRUNCATE 옵션을,
어떤 것을 쓰면 좋을까요? ^^ wvnsprintf, _vsnwprintf_s, StringCbVPrintfW
; https://www.sysnet.pe.kr/2/0/1622
다음과 같이 사용할 수 있습니다.
wchar_t buf[3];
errno_t ret = wcsncpy_s(buf, 3, L"test", _TRUNCATE);
if (EINVAL == ret || ERANGE == ret || STRUNCATE == ret)
{
cout << ret << endl;
}
그럼, 함수의 반환값으로 오류 상황도 알 수 있고 비정상 종료도 경험하지 않을 수 있습니다.
참고로, SecureCRT의 경우 버퍼의 크기를 명시하지 않는 template 버전으로도 사용할 수 있습니다.
void main()
{
wchar_t buf[3];
wcscpy_s(buf, L"test"); // template 확장 ==> wcscpy_s<3>(buf, L"test");
}
Visual C++ 컴파일러는 위와 같은 코드의 경우 다음의 함수를 선택해 주는데,
template <size_t size> errno_t wcscpy_s(wchar_t (&strDestination)[size], const wchar_t *strSource);
template 문법이기 때문에 당연히 C++ 소스 코드에 대해서만 사용이 가능합니다. 이 함수의 장점이라면 기존에 사용하던 소스 코드를 마이그레이션할 때 단순히 함수의 끝에 "_s" 접미사만 붙여주면 된다는 것입니다. 하지만 당연한 제약이 하나 있는데, 포인터 변수의 경우 그것의 버퍼 크기를 알 수 없으므로 다음과 같은 경우에는 _s 접미사를 붙이면 컴파일 오류가 발생합니다.
void my_copy(wchar_t *dest, const wchar_t *source)
{
wcscpy_s(dest, source); // 컴파일 오류 Error C2660 'wcscpy_s': function does not take 2 arguments
}
따라서, 저런 식의 코드에서는 SecureCRT 함수로의 전환이 다소 번거롭게 되는데 왜냐하면 모든 함수에 버퍼 크기를 전달해 줘야 하기 때문입니다. 즉, 다음과 같이 해야 합니다.
void my_copy(wchar_t *dest, int dest_len, const wchar_t *source)
{
wcscpy_s(dest, dest_len, source);
}
C 파일의 경우 template 지원이 안되므로 이에 대한 사용을 주의해야 합니다. 가령 다음과 같이 사용하면,
void Test()
{
char buf[3];
strcpy_s(buf, "test");
}
컴파일 오류 없이 경고만 이렇게 뜹니다.
warning C4013: 'strcpy_s' undefined; assuming extern returning int
실행하면, (당연히) strcpy_s는 3개의 인자를 요구하는 버전이 실행되므로 스택 밸런스가 맞지 않아 예외가 발생하게 됩니다. 따라서, (C++가 아닌) C 소스 코드를 마이그레이션 할 때는 경고를 주의 깊게 봐야 합니다.
마지막으로! SecureCRT는 보완하는 용도일 뿐 해결책은 아니라는 점입니다. 가령, 다음과 같이 개발자가 버퍼 크기를 틀리게 입력해도 SecureCRT 함수는 이에 대해 책임질 수 없습니다.
wchar_t buf[2];
wcscpy_s(buf, 4, L"test");
위의 코드는, 이전과 마찬가지로 Debug 모드에서는 __security_cookie + __RTC_CheckEsp 덕분에 assert 창이 뜨지만 Release 모드에서는 결과를 예측할 수 없게 됩니다.
(
첨부 파일은 이 글의 예제 코드를 포함합니다.)
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]