This post originated from an RSS feed registered with .NET Buzz by Chris Flaat. Original Post: Don't take code (or solutions or projects) from strangers Feed Title: Chris Flaat's Weblog Feed URL: /msdnerror.htm?aspxerrorpath=/cflaat/Rss.aspx Feed Description: I mainly discuss tips & tricks about VS 2002, VS 2003, and upcoming versions of VS. Latest .NET Buzz Posts Latest .NET Buzz Posts by Chris Flaat Latest Posts From Chris Flaat's Weblog

Greetings, my dear readers.  I wanted to offer some suggestions about how VS users can safely handle code obtained from other sources.  A combination of common sense and careful reading of the VS documentation would lead you to the same conclusions I’m laying out here, but I thought it might be helpful to summarize these tips in one place.

Now, most of you hopefully know that if you get a program from someone else via e-mail or on some other medium, it is extremely unwise to actually run that program unless you really understand what it is.  If it turns out to be a malicious program, then any manner of terrible things might happen: you might lose all your data, your data might be sent to someone else, virus-carrying e-mails might get sent to your friends & associates, etc.  And nasty programs can be transmitted via other files besides .exe’s: batch files, word processing documents, spreadsheets, etc.

What about Visual Studio solutions and projects?  My guidance to you is simple: Do not open, build, or run solutions or projects from untrusted sources.  They could be malicious and could be every bit as dangerous as running a malicious executable.  Treat them with the same care you’d give an untrusted .exe.  I’ll discuss ways to mitigate this such that you can try to work with code from an untrusted solution or project without getting burned, but understand that this course of action is inherently risky.  If in doubt, don’t even open a solution or project from an untrusted source, and for heaven’s sake don’t build or run it.

Now, perhaps I’ve scared some of my dear readers with the above statements.  But none of this should be too surprising if you think about what a solution or project is.  A solution or project expresses how to build a program (which itself could be malicious).  So you not only have a potentially evil program, you have a bunch of other associated operations that help to design & build that program, which themselves could be evil.  Note that at an abstract level, it’s not really any different than if you downloaded a .cpp file and a makefile – if the makefile erases your hard drive instead of compiling the code, it doesn’t really mean NMake.exe is inherently bad; it means you were foolish to invoke a makefile from an untrusted source.  Makefiles are inherently powerful; so is VS.

If you do want to be able to grab code from other sources, then read on and I’ll offer some tips so that you can better understand how to manage the inherent risks of doing so.

One note about VS 2002 and VS 2003.  If you’re still using VS 2002, consider upgrading to VS 2003.  This isn’t some sales pitch I’m making in order to boost the stock price.  VS 2003 has a lot of small improvements, including security-related ones, that make it a valuable upgrade from VS 2002.  However, the advice I’m giving here still generally applies if you use VS 2002.

Now, I had originally wanted to describe this stuff starting with the simple cases and then working up to the complex ones.  However, the most complex case, the issues with opening a solution or project, are the first thing one is likely to run into, so I’m going to tackle that first.

Why is it potentially dangerous to simply open an untrusted VS solution?  Well, if you’ve read the VS documentation carefully (e.g. this page), you might have noted some ominous warnings about how opening up the VS.NET forms designer can run code in your project, and therefore you need to ensure that the code is trustworthy before opening it in the designer.  I’ll not go into the deep, dark details of this (after all, I don’t want to make it any easier for people to do harmful things), but suffice it to say that a project can be constructed such that merely opening up a form can cause (potentially evil) code in the project to be executed.

In VS 2002 this could be very dangerous because if you opened up a solution we would also look at your .suo file, which has a list of what files to open up when the solution is opened.  So…if you created an evil solution that would run evil code when the designer is used on a form, and your .suo indicated that the form should be opened when the solution loads, simply opening up the solution file would cause the evil code to be run.  In VS 2003 this is mitigated to some extent; in VS 2003 we don’t automatically open any files listed in the .suo unless the .suo was created on your machine.  Therefore if you’re using VS 2002 and you decide to ignore my advice about opening untrusted solutions/projects (please don’t!), you would definitely want to delete anyone else’s .suo file before proceeding.

However, even with that change in VS 2003, opening up an untrusted solution is still dangerous.  If you open the forms designer on an evil file, you’re toast.  Plus, if you then build or run the solution, you’re potentially toast as well, as we’ll discuss shortly.  This is why I’m giving the general recommendation to avoid opening untrusted solutions / projects in VS -- it’s just so easy to get into trouble, even if you’ve managed to safely open it.

Let’s talk about running & building an untrusted solution or project.  Taking an untrusted solution/project and running it (e.g. by hitting F5) is extremely foolish.  It’s basically the same thing as taking an untrusted .exe and running it.  True, you can see the source code, but it’s not hard to do evil things with innocent-looking source code.  Even stepping into the program with the debugger (e.g. hitting F11) may not be safe, since obscure initialization code might get run before the entrypoint that you’ll be stepping into.

Building an untrusted solution or project is likewise hazardous.  It’s easy to insert nastiness into the build process (running an .exe in a custom build step is one way, and there are many others).

The best thing to do is only take code from sources that you can reasonably trust, like from resources inside your organization, people you personally know, from companies or authors that you trust, etc.

If you wish to use code from a source you do not fully trust, the best thing to do is take little snippets that do exactly what you want and which you can fully understand.  For example, if you want to learn about drawing graphics with DirectX, create your own program and try to find snippets to do exactly what you want (e.g. drawing a circle on the screen).  This is much safer than grabbing some huge sample program from a random place on the web where you can’t be sure of who wrote it or whether they are trustworthy.

If you want to grab some big, complex project or solution from an untrusted place on the web, stop and assess your sanity.  If you believe that you are on the correct side of the sanity line, you are an expert on the language & API’s the code is written with, and you understand that you are taking a huge and rather foolish risk, then here’s my advice as to how to defend against disaster:

1)      Take only the code files (the .cpp files, .cs files, .vb files, etc.).  Do not take the .sln, .suo, .*proj, etc. files.  Likewise, do not take makefiles, NAnt files, batch files, etc. as these can also be malicious.

2)      Open each code file in isolation and read every line.  Do not open it in the VS forms designer.  Instead, use the Open With feature of VS (detailed in one of my earlier blog entries) to view it with the VS source code editor or just use Notepad.

3)      Inspect every line.  If you see anything that either looks dangerous or which you don’t understand, don’t go any further until you figure out what it does and why.  You are on your own, and responsible for the consequences of not fully understanding the code.

4)      Create your own VS solution & project (don’t use the one that came with it).

5)      Add the files that you’ve inspected & that you believe are safe to your newly created project.

6)      Take a deep breath and do some soul searching as to whether you really want to go any further: at this point opening files in the designer or running the program will lead to disaster if you missed something in step #3.

One thing I also want to make clear is that most of these issues apply to any code and any development environment.  If you obtain makefiles, batch files, perl scripts, awk scripts, etc. from an untrusted source, they are potentially dangerous if you run them.

I hope this information is useful, and I hope I’ve made it clear that untrusted solutions, projects, and code need to be handled with the utmost care.  I’d love to hear any comments that readers have on this topic.  If you have comments, please add a blog comment.

Bye for now! –Chris

[Please note: This weblog entry is provided "AS IS" with no warranties, and confers no rights.  Opening and/or using solutions or projects from untrusted sources is inherently dangerous and the author, Chris Flaat , does not recommend it.  If you attempt to open and/or use a solution or project from an untrusted source, then you do so at your own risk.]