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
Usage of CoreRun.exe >
Windows version

CoreRun.exe is not constrained by the Windows version, other than by the fact of having to be 64-bit (and including a supported .NET version, as discussed in the next section); at least, this is the case with the tested Windows 8 and 10. Nevertheless and as explained in the previous section, it should be noted that I didn't perform a detailed analysis of the source code.

At a first sight, converting the target platform of the CoreRun.exe source code into 32-bit seems acceptable (i.e., simple enough to comply with the "only threat if no relevant modifications are required" idea which underlies this whole project), but such an assumption doesn't hold. Although there is a functional Visual Studio project, it has many external dependencies which would also need to be adapted (i.e., relevant number of errors when changing the target platform from 64-bit to 32-bit).

Although creating a 32-bit version of CoreRun.exe isn't trivial, assuming that it will be exclusively used on 64-bit OSs no matter what would also be disproportionate. This 32-/64-bit differentiation represents one of the multiple layers of complexity which decrease the likelihood of CoreRun.exe being a real threat: the more constrained its usage conditions, the less likely to be something about which to worry.