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 >
Likelihood of threat occurrence

The conditions of the scenario proposed in the previous section are threat-favourable enough to allow general conclusions about the likelihood of a threat to occur at all. Different conditions might certainly provoke relevant changes on the relevance of some of the aspects below, although the final conclusions should remain unaltered.

The following requisites have to be met in order to allow the threat in the proposed scenario to become effective:
  • As explained in some of the previous sections (i.e., Minimum requirements, Windows version and Visual Studio & .NET version), CoreRun.exe cannot be run on any computer independently upon its configuration. Examples: supported version of Visual Studio installed and 64-bit OS.
  • Additionally to meeting the aforementioned requirements, CoreRun.exe needs to access various files in OS-privileged locations (e.g., Windows directory when running on Windows). Hence, employee E would need to have administrative privileges on the given computer; this is considered an unsafe practice and, consequently, rarely happens in this kind of situations.
  • Employee E (or his associates) needs to have a solid background in .NET, programming and IJK; ideally, he should also have a good understanding of IJK's source code.
  • Employee E (or his associates) will have to perform a relevant number of tests to make sure that the IJK behaviour will be as normal in appearance as possible. Note that guessing the implications (i.e., without in-depth tests) of relying on modified CoreCLR libraries is virtually impossible when dealing with a more or less complex piece of software.
  • All the aforementioned points might even be ignored on account of the tremendous difficulty associated with deciding the modifications to be performed. Theoretically, IJK might be completely changed; practically, even the slightest variation in the CoreCLR libraries might provoke a huge cascading effect which will be very difficult (or even impossible) to be fixed. For example: redefining string would not only affect all the variables of this type in the IJK source code, but also any used .NET functionality relying on this type at any point (i.e., virtually all the in-built functionalities would be affected).
In summary, using CoreRun.exe to modify the behaviour of a random .NET executable without having access to the source code is impractically complex. Even in case of having access to the source code, the associated difficulty would be very high. Thus, the conclusion of this section is that the likelihood of threat occurrence (i.e., using CoreRun.exe to make a .NET executable behave against its intended purpose) is virtually zero.