Untrustworthy Projects in Visual Studio? -


when opening project may have downloaded, visual studio 2013 briefly warns open projects trustworthy sources. of risks opening projects? can project harm system before compilation, , damage possible? there indicators should aware of before opening projects "untrustworthy" sources? (not can think of any)

attack surface within visual studio

there many attack vectors within visual studio. of them design. developers want complete control on our systems within build process. unfortunately, when "i want delete contents of cache directory on build", means malicious project files can delete anywhere. or worse. compromise "hey. we've given keys kingdom, don't recognize project. sure want open this? we're not responsible if stupid" warning message mentioned.

now consider many developers run visual studio administrator.

here of attack vectors:

pre- , post-build events
in it's simplest form, untrusted projects execute pre-build event delete files. or worse. can executed within build event. 101 stuff happens on compile.

executions on project open
visual studio project files nothing more big msbuild configurations. there few msbuild targets visual studio executes when open project, support tooling. these targets include compile, resolveassemblyreferences, resolvecomreferences, getframeworkpaths, , copyrunenvironmentfiles. if of these targets exist, tasks within them executed. delete files, or worse.

see: 'design-time execution' @ http://msdn.microsoft.com/en-us/library/ms171468.aspx

intellisense
part of tooling mentioned above includes intellisense, executes compile task within msbuild; csc/vbc must executed of intellisense functionality. because of nature of intellisense, task repeatedly executed work, rather opportunities above run once on open.

see: 'design-time intellisense' @ http://msdn.microsoft.com/en-us/library/ms171468.aspx

hidden elsewhere in msbuild
there sea of other routine msbuild targets manually execute throughout day, including build, rebuild, test, , clean. yes, keep in mind clean build target, clean delete more old \bin directories.

nuget
malicious projects may expose systems via nuget. though package restore not issue, packages.config specify different repository source. then, when install new package, such install-package jquery, nuget retrieve jquery package untrusted alternate, rather nuget.org. malicious jquery package have sorts of other 'goodies' within executed part of package installation.

this not security vulnerability nuget, because "you" specified alternate package source; design, such corporations have own internal package repository.

what can do?

at end of day, can this? answer not open projects untrusted sources. project's packages.config file analyzed before open it, big exposure through msbuild. unless quite adept @ reading through msbuild schema, steer clear.


Comments

Popular posts from this blog

android - Get AccessToken using signpost OAuth without opening a browser (Two legged Oauth) -

org.mockito.exceptions.misusing.InvalidUseOfMatchersException: mockito -

google shop client API returns 400 bad request error while adding an item -