Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Security

Secure Coding in C++/CLI


Robert C. Seacord is Senior Vulnerability Analyst for CERT/CC. He can be reached at [email protected].


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. }
Listing One

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().


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.