Project 8
Completed (26 days)

Introduction >

Usage of CoreRun.exe >

Minimum requirements

Security analysis >

Completed (47 days)
Completed (19 days)
Completed (14 days)

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

This project comes from the assumption that CoreRun.exe can be a security threat because of allowing to easily modify .NET applications. It has to be noted that "easily" is a very important part of the previous sentence, equivalently to what happens in the definition of any other software security analysis. This point is specially worth noting here on account of the fact that the source code of CoreRun.exe has been made publicly available.

The aforementioned paragraph explains why this section and the next two ones, Windows version and Visual Studio & .NET version, are needed: the default constraints of CoreRun.exe (i.e., how easily the default version can be used under different scenarios) is a key part of the current analysis. Additionally, there are other issues to bear in mind in order to properly understand this project:
  • Neither CoreRun.exe nor the Visual Studio files associated with it (e.g., CoreRun.sln) can be found in the CoreCLR repository, but just the C++ files containing its source code. The executable and the VS files are included among the outputs generated when building the whole CoreCLR code (i.e., running build.cmd); in Windows machines, these files are stored under \bin\obj\Windows_NT.x64.Debug\src\coreclr\hosts\corerun\.
  • I did all my tests on Windows 8 & 10 (64-bit). That's why I am not completely sure whether the conclusions of this project are also applicable to other operating systems, although this seems the most likely scenario.
  • The majority of this project has been focused on testing CoreRun.exe under different conditions, rather than on analysing its source code. Nevertheless, I did skim through the code and did perform slight modifications on it as a way to confirm certain assumptions. Doing a more detailed analysis of the code would have been against the aforementioned expectations of this project (i.e., CoreRun.exe being an immediate security threat).

Basic CoreRun.exe requirements:
  • 64-bit Windows version. Its target platform is 64-bit, equivalently to what happens with all the CoreCLR code.
  • Visual Studio installed. CoreRun.exe requires certain files which are present in the supported versions of VS.
  • Using it with a .NET executable. For example: typing "CoreRun.exe MyExecutable.exe" in the command prompt, where MyExecutable.exe was built on a .NET language.
  • Including all the required libraries in the same directory than CoreRun.exe; at least, coreclr.dll and mscorlib.dll. In this context, "required" means used by the given .NET executable. For example: if MyExecutable.exe relies on Decimal.Parse, the library including this method would have to be included (i.e., mscorlib.dll).