May 16, 2006
Secure Coding in C++/CLI
Assuming that lpszGuestPassword is located at 0x002DEB9C, you can examine the contents of the stack by examining memory at this location. Through debugging the example program or by trial and error, it is possible to determine that the return code of 0x004f3a99 is located at the address 0x002DEBD0 in the stack (see Example 4).
002DEB9C 4e 00 43 00 43 00 2d 00 31 00 37 00 30 00 31 00 002DEBAC 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 002DEBBC 1e df b4 bd 00 00 00 00 50 15 40 00 64 ec 2d 00 002DEBCC ec eb 2d 00 99 3a 4f 00 05 27 00 01 00 00 00 002DEBDC b0 32 2f 00 84 ec 2d 00 da c4 fc 79 58 f1 2d 00
Example 4: Examining memory from 0x002DEB9C.
Assuming that the shellcode has been injected into the program at 0x00409028, an attacker can enter this string at the password prompt in the Login dialog box:
"1234567812345678\xebcc\
x002d\x9028\x0040"
Methods for reading hex codes as input for Unicode characters can be found at www.fileformat.info/tip/ microsoft/enter_unicode.htm. The contents of memory in the data segment after the buffer overflow is shown in Example 5.
0040911C 31 00 32 00 33 00 34 00 35 00 36 00 37 00 38 00 0040912C 31 00 32 00 33 00 34 00 35 00 36 00 37 00 38 00 0040913C cc eb 2d 00 28 90 40 00 00 00 ff ff 8a 00 07 00 0040914C c6 00 07 02 02 01 07 02 00 00 00 00 01 00 00 00
Example 5: The contents of memory in the data segment after the buffer overflow.
The brown bytes show where the value of userP has been overwritten with the address of the return code on the stack (minus four), and the green bytes show where the value of userNameLen has been overwritten with the address of the shellcode. After the arbitrary write on line 124 is executed, the stack now appears as in Example 6.
002DEB9C 4e 00 43 00 43 00 2d 00 31 00 37 00 30 00 31 00 002DEBAC 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 002DEBBC 1e df b4 bd 00 00 00 00 50 15 40 00 64 ec 2d 00 002DEBCC ec eb 2d 00 28 90 40 00 0e 05 27 00 01 00 00 00 002DEBDC b0 32 2f 00 84 ec 2d 00 da c4 fc 79 58 f1 2d 00
Example 6: After the arbitrary write on line 124 is executed.
The bytes shown in red illustrate where the return code on the stack has been overwritten with the value of the address code. No other bytes on the stack (including the canary) are modified, making this attack undetectable by the runtime system. As a result, control is passed to the shellcode when the GetPassword() function returns.
This second case is interesting for a variety of reasons. First, it demonstrates that the return address on the stack can still be overwritten—even with buffer security checks (/GS flag) enabled, as these checks only mitigate overflows for automatic buffers declared on the stack. Second, it shows that a program can compile cleanly without warning in the Visual Studio 2005 environment and still be vulnerable. Listing Three eliminates the buffer overflow. Before sending the message, the first word of lpszPassword must be set to the size, in TCHARs, of the buffer. For Unicode text, this is the number of characters. The size in the first word is overwritten by the copied line. Also, for edit controls the copied line does not contain a terminating null character. The return value (the number of TCHARs copied) must be used to null-terminate the string.
LRESULT Retval; *((WORD *)(&lpszPassword)) = (sizeof(lpszPassword)/sizeof(TCHAR))-1; Retval = SendDlgItemMessage(hDlg, IDC_EDIT1, EM_GETLINE, (WPARAM) 0, // line 0 (LPARAM) lpszPassword ); lpszPassword[Retval]='\0';
Listing Three
Acknowledgments
I would like to acknowledge Dan Plakosh and Hal Burch and Andrew M. for their help in developing the programming examples and Tim Shimeall, Louis Lafreniere, and Pamela Curtis for reviewing the article.
References
Previous Page |
1 Secure Coding in C++/CLI
|
2 Vulnerabilities
|
3 GS Option
|
4 More Vulnerabilities
|
 |
|
||||||||||||||||||||||||||||||
|
|
|
