Completed (26 days)
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.
CoreRun.exe can modify the behaviour of any .NET executable by forcing it to rely on an altered version of some of the libraries which define its pure essence. Thus, any potential threat scenario has to include, additionally to CoreRun.exe, an existing application built on a .NET language and (modified versions of) various CoreCRL libraries.
Let's imagine that employees at bank XYZ rely on the .NET program IJK to browse through the information of their clients. On their computers, they run a local copy of IJK which is connected to the central database. While dealing with client C, employee E runs IJK via CoreRun.exe together with a set of specially-modified CoreCLR libraries (i.e., by typing "CoreRun.exe ijk.exe" rather than the usual "ijk.exe"). This provokes IJK to run notably slower and to show slightly different screens and even errors; but nothing of this is noticed or seen as a problem by the client.
What kind of modifications can E do on IJK? Theoretically, he might change anything. Examples: