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 <font color="#663300">99 3a 4f 00</font> 05 27 00 01 00 00 00
002DEBDC   b0 32 2f 00 84 ec 2d 00 da c4 fc 79 58 f1 2d 00

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   <font color="#663300">cc eb 2d 00</font> <font color="#00FF00">28 90 40 00</font> 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

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 <font color="#FF0000">28 90 40 00</font> 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

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';

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

1. [1] Seacord, Robert C., Daniel Plakosh, and Grace A. Lewis. Modernizing Legacy Systems: Software Technologies, Engineering Processes, and Business Practices. Addison-Wesley, February 2003.
2. [2] Seacord, Robert C. Secure Coding in C and C++. Addison-Wesley, 2005 (ISBN 0321335724).
3. [3] Meyers, Randy. "Specification for Safer, More Secure C Library Functions," ISO/IEC TR 24731, June 6, 2004.