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.
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:
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.