Security implications of open CoreCLR (CoreRun.exe)
Completed on 05-Feb-2016 (26 days) -- Updated on 23-Nov-2016

Some of the conclusions of this project aren't applicable anymore.
To know more about all this, read "OVER-8-MONTH-LATER UPDATE" in the Open .NET & CoreCLR section.

Project 8 in full-screenProject 8 in PDF
Security analysis >
Conclusions

The first and most important conclusion of this project is that CoreRun.exe isn't a security threat. In the sense that there is little chance of someone using it to make a .NET executable perform unintended actions. I am not sure whether Microsoft paid special attention to these aspects or whether this is just a fortuitous consequence from a so complex reality; either way the final result seems good enough from a security point of view.

On the other hand, the chosen approach doesn't seem ideal and concluding its suitability to be a threat or not is certainly not trivial. Note that CoreRun.exe can modify the most essential parts of virtually any .NET application by just taking it as an argument (i.e., writing in the command prompt "CoreRun.exe NameOfFile.exe"); this seems a bit too excessive on account of the CoreRun.exe's purpose (i.e., validating modifications in some .NET libraries). In the most likely scenario, programmers will create small applications to test their modifications on the CoreCLR libraries, rather than using random .NET executables (i.e., what CoreRun.exe unnecessarily allows).

CoreRun.exe delivers what is expected and doesn't represent a clear threat to the .NET security. On the other hand, it is a quite peculiar approach giving out much more than strictly required, what is rarely a good idea when dealing with software.