Don't take code (or solutions or projects) from strangers

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.

"urn:schemas-microsoft-com:office:office" />

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 u/>sing
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.]