Child-Application Attacks | Security for Microsoft Visual Basic .NET

If you use the Shell statement or some other mechanism to dynamically load other applications (child applications) at run time, you need to take defensive measures to prevent unwanted applications from being loaded and executed. For example, if you’re attempting to run an application where the path to the application contains spaces such as ‘C:\PROGRAM FILES\MyApplication\MyApp.Exe’ or ‘C:\DOCUMENTS and SETTINGS\MySubApplication\SubApp.Exe’, your application could end up loading any application that matches a portion of the path. This is similar to how you could inadvertently open a file in an unexpected location if the path is not in canonical form, as you learned earlier. If an application named C:\PROGRAM.EXE exists, the following Shell statement would inadvertently execute it:

Shell(“C:\PROGRAM FILES\MyApplication\MyApp.Exe”)

The reason this happens is that the space separating PROGRAM from FILES leaves the path statement open to interpretation. If Windows is presented a path such as this, its lookup strategy for that path is as follows:

Take the name preceding the space (C:\PROGRAM), and check for a program named C:\PROGRAM.EXE and pass FILE\MyApplication\ MyApp.Exe as a command-line parameter to PROGRAM.EXE.
Proceed to the next space in the path, and check whether there is an executable associated with the name preceding the space (as in the previous step).
Repeat the previous step until the end of the string is reached and no executable programs are found.
If the end of the string is reached, attempt to execute the full path and file name given—in this case, “C:\PROGRAM FILES\MyApplication\MyApp.Exe”.

If an attacker could install a program named C:\PROGRAM.EXE on your computer, the program would lay dormant until you ran your Visual Basic .NET application (and the Shell statement contained within it). When the Shell statement executed, C:\PROGRAM.EXE would spring to life, unleashing whatever ill will the (PROGRAM.EXE) program’s author had in mind.

Note

The amount of damage the attacker’s application can unleash in this situation is dependent on the privileges your logged-on user account has. For example, if you are logged on as the system administrator, the attacker’s application could do extensive damage to the system. If you are logged on using a local user account, the potential for damage might be much less, depending on the operating system and configuration settings. See Chapter 11 for more information on changing configuration settings to adopt a least-privilege approach by giving yourself no more permissions than you need.

Defensive Technique for Child-Application Attacks

The following defensive technique can be used to prevent a child-application attack.

Use Quotes Around All Path Names

To prevent the path from being subject to interpretation, put double quotes around all path and file names. For example, the Shell statement shown previously should be changed to:

Shell("""C:\PROGRAM FILES\MyApplication\MyApp.Exe""")

With double quotes surrounding the filename, the Shell statement (and Windows) will be left to interpret the path and file name one way, as “C:\PROGRAM FILES\MyApplication\MyApp.Exe", avoiding the execution of other applications along the way.

Buffer Overrun

In “Writing Secure Code” (Microsoft Press, ISBN 0-7356-1588-8), Michael Howard and David LeBlanc identify the buffer overrun as public enemy #1. This issue has been to blame for a number of high-profile security exploits and for many security holes being uncovered and fixed in a number of applications and system components. Many security fixes you can download and install from the Microsoft security Web site address buffer overruns, so you should stay current with the latest updates and service packs.

The applications and components mainly at risk for buffer overrun attacks are written in languages such as C and C++, which let you allocate buffers such as string buffers, byte array buffers, or arbitrary structures directly on the stack. In fact, in those languages it’s quite easy to write code that leads to a buffer overrun if you’re not careful. In Visual Basic .NET (or any .NET language, such as C#, for that matter), it’s much more difficult to write code that leads to a buffer overrun. Your Visual Basic .NET applications are largely immune to this problem because Visual Basic .NET does not let you:

Allocate buffers on the stack
Copy strings or other data to a fixed-length buffer, where you can copy data past the end of a buffer

Languages such as C++ let you do both. Visual Basic .NET allocates—by means of the .NET runtime—your strings and other data in a separate area of memory away from the stack. However, this does not make your Visual Basic applications (or other .NET languages for that matter) completely immune to the risk of being exposed to a buffer overrun.

If your code makes calls to external functions declared with the Declare statement that are written in another language—such as C, or C++—or uses ActiveX components, your application might be a security risk for a buffer overrun.

In a buffer overrun attack, the attacker attempts to overwrite memory in your computer (or on the server); the goal is to be able to overwrite memory that controls the flow of execution for your application. If the attacker is clever or lucky enough, he can force a buffer overflow, change the flow of execution, and redirect your application to execute code embedded in the input he passes in. The effect is the same as if the attacker wrote his own application, installed it on your computer, and executed it without your permission. While running on your computer, the application could perform whatever actions it chooses within the bounds of what you as a user could do on the computer—that is, it has enough permissions to overwrite your personal files or copy them to another location.

Here are steps you can take to avoid buffer overrun attacks:

Avoid using ActiveX components or making API calls in your Visual Basic .NET application. If you’re using ActiveX components or making API calls, strive to replace the ActiveX components and API calls with .NET components and calls to .NET framework functions, respectively.
Scrub all data being passed to an ActiveX control property or method. Check the length of the data as well as its content. For example, you can use the Regex class to locate and remove any unwanted characters before passing data on to the component.
If you call a function that requires both a string and the length of the string as input parameters, use the Length method of the string or the Len function to dynamically compute the string length at the time the function call is made. Do not pass a hard- coded value for the length of the string. If you change the code in the future to make the string shorter but forget to update the length parameter, you might open your code to be exploited by a buffer overrun attack.