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.
As far as Project 7
already includes my impressions about open .NET and my first participation there, visiting that project is precisely the best way to get some Preliminary ideas. More specifically, the following (Introduction
I came up with the idea of creating the current Project 8 after realising about the peculiarities associated with the compilation/validation of the CoreCLR code. Note that compiling this whole code (or one of its main parts, like mscorlib.dll
) is not strictly required when working on it. For example: I didn't consider whole-CoreCLR-compilation aspects while performing all the relevant tests and drawing the main conclusions in Project 7.
In summary, this project will be dealing with CoreCLR by focusing on compilation aspects and closely-related issues (e.g., CoreRun.exe
and its impact on security), rather than on specific pieces of code (what Project 7 is precisely about).
As explained in the also-updated Project 7, Microsoft has modified the way in which .NET programs can communicate with the CoreCLR libraries (and with the ones in other repositories, like CoreFX). This fact has a big impact on the current project, as far as its whole purpose was precisely analysing what is now an obsolete proceeding. Nevertheless and except for this clarification, I will keep it as originally written because of describing one of the preliminary steps within the evolution of a complex framework.
The most relevant ideas can be summarised in the following points:
- Originally, CoreRun.exe could be used with any .NET executable right away (e.g., in a folder including the required DLLs, CoreRun.exe and MyApp.exe, MyApp.exe could be run on the new libraries by typing "CoreRun.exe MyApp.exe" in the command prompt). In fact, I firstly thought about starting this project because of intuitively considering that such a proceeding was intrinsically unsafe.
- The (main) new approach relies on the .NET Core Runtime to build the source code being tested (this new proceeding is explained here). There is also a reference to a CoreRun.exe-based alternative (described here), which differs from the old one. Additionally, the CoreFX tests rely internally on CoreRun.exe; what can be easily confirmed by running any of these tests from Visual Studio and seeing that it is the associated process. In any case, the old performance dropdown isn't occurring anymore.
- At the moment, CoreRun.exe cannot run other .NET programs as described in the current project. Note that even previously-running-fine backups aren't working now on the same computer.