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 >
Sample scenario

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:
  • Redefine basic types. Any action might be triggered by the constructor of any type, by consequently having full control on any variable of this type or on a specific subgroup of them (e.g., the ones whose names include the words "account" or "connection"). For example: all the values assigned to string variables might be written to an external file.
  • Alter OS-related information. The values of any System.IO variable might be changed, what would seriously affect IJK's I/O system. For example: it might be forced to read from/write to specific files and locations.
  • Affect the behaviour of basic elements of the programming language. Certain type of events (or even all of them) might be modified in any way. For example: a new window asking for a password might be triggered when clicking on a button with certain name.
The proposed example depicts the ideal conditions under which CoreRun.exe might be used to modify the behaviour of a .NET executable against its original purpose. A presumably trustworthy person (bank employee) using a program apparently as expected; and without the victim fully understanding or seeing the performed actions (errors or weird behaviours might occur). The required requisites and assumptions will be analysed in the next section.