Visual C++ 2005 expands support for developing components and applications that run on a virtual machine with garbage collection using C++/CLI (the Common Language Infrastructure). C++/CLI is an extension of the C++ programming language that adds features such as properties, events, garbage collection, and generics for all types including existing Standard C++ classes.
Visual C++ 2005 supports the .NET Framework Common Language Runtime (CLR), Microsoft's implementation of a garbage-collected virtual machine. The C++ syntax supported in Visual C++ 2005 for .NET programming has evolved significantly from the managed extensions for C++ introduced in Microsoft Visual C++ .NET 2003. Managed extensions for C++ are still supported but have been deprecated in favor of the new syntax. Visual C++ 2005 also adds new features for native programming, including targeting 64-bit processor architectures and new library functions with improved security,
In this article, I examine C++ programs that are minimally ported to this new environment using managed extensions. This involves porting an existing legacy system to this environment [1] with minimal effort (a common approach by understaffed and overworked software maintenance teams). The purpose is to determine whether these programs are still susceptible to the buffer overflow vulnerabilities that have plagued C and C++ programs [2].
Listing One prompts users for a username and password. Regardless of the username, the program only accepts "NCC-1701" as a valid password. If the user fails to enter the proper password, the program exits. (This program is intended as a test for vulnerabilities in C++/CLI code and not as an exemplar of how to handle passwords.)
1. #include <stdlib.h>
2. #include <stdio.h>
3. #include <windows.h>
4. char buff[1028];
5. struct user {
6. char *name;
7. size_t len;
8. int uid;
9. };
10. bool checkpassword() {
11. char password[10];
12. puts("Enter 8 character password:");
13. gets(password);
14. if (strcmp(password, "NCC-1701") == 0) {
15. return true;
16. }
17. else {
18. return false;
19. }
20. }
21. int main(int argc, char *argv[]) {
22. struct user *userP = (struct user *)0xcdcdcdcd;
23. size_t userNameLen = 0xdeadbeef;
24. userP = (struct user *)malloc(sizeof(user));
25. puts("Enter user name:");
26. gets(buff);
27. if (!checkpassword()) {
28. userNameLen = strlen(buff) + 1;
29. userP->len = userNameLen;
30. userP->name = (char *)malloc(userNameLen);
31. strcpy(userP->name, buff); // log failed login attempt
32. exit(-1);
33. }
34. }
Execution starts on line 21 in main(). The program prompts for a username on lines 25 and 26 using a combination of puts() and gets(), resulting in an unbounded string copy from standard input into the buff character array declared on line 4. This is one of two locations in the program where a buffer overflow vulnerability can occur. The checkpassword() function is called from line 27 of main(). The checkpassword() function prompts users for a password on lines 12 and 13, also using a combination of puts()/gets(). This second call to gets() can also result in a buffer overflow in the password character array defined on the stack.
The program is compiled using Microsoft Visual C++ 2005 with the buffer security check option disabled (/GS-) and managed extensions enabled (/clr). The buffer security check is enabled by default, and it is generally a bad idea to disable it (as this example demonstrates). The /clr setting allows mixed assemblies consisting of managed and unmanaged code.
There are several warnings during the build process that are ignored; for example, "warning C4996: 'gets' was declared deprecated" and "warning C4996: 'strcpy' was declared deprecated." The compiler recommends using gets_s() instead of gets() and strcpy_s() instead of strcpy(). If these replacement functions are used properly, the possibility of buffer overflow would be eliminated [3]. However, these are only warnings and can be ignored (or even disabled). Ignoring these warnings is consistent with the scenario of minimally porting an existing legacy system.
When using managed extensions, the compiler generates Microsoft Intermediate Language (MSIL) (renamed the Common Intermediate Language or CIL as part of the standardization process) for main() and for the checkpassword() functions. The CIL bytecodes are packaged into an executable that invokes the just-in-time compiler (JIT) to translate these bytecodes into native assembly instructions and then transfers control to main().
