Security Risk Feature: Packaging C# and DLL's into FHIR Resources

[baseTwo]

Intro

At the moment, the packager CLI has the ability to convert ELM to C# and .NET libraries. Furthermore the tool packages the C# and .NET DLLs into library and measure FHIR resources.

Uploading these to a FHIR Server to be executed is a major security concern as it leaves the server vulnerable to a range of trojans, malicious code or information theft.

Realistically only CQL and ELM should be included into a FHIR Resource. It is up to a FHIR Server to be able to compile these into its own native executable code.

Solution

The Packager CLI must be changed so the default behaviour is to only include CQL and ELM into FHIR Resources. It must still be possible to include C# and compiled .NET assemblies, but through a flag on the command line.

It's worth considering outputting what the risks are if this is selected, to the console and log file

[alexzautke]

As an alternative we could consider to code signatures on the DLL output. I would recommend to add that functionality in any case. Even if the FHIR server creates the DLL based on the CQL/ELM, we should protect the code against direct manipulation and be able to verify that the code is still the same code that was initially created.

[and-hus]

Unfortunately, we are currently using exactly this feature ...
Would it be possible to keep the packaging of the .net assemblies into the FHIR Resources as an optional feature behind a commandline flag?

[baseTwo]

We could consider including the C# and DLL's in the FHIR resource if so requested with an optional flag

[and-hus]

That would be great. Thanks!

[EvanMachusak]

We're using it too, but are considering moving away from it. Another problem you can run into is when a measure is written with references to Firely SDK 5.10 and your execution environment loads Firely SDK 5.8. It's best if your consuming environment compiles the assemblies and caches them within itself, rather than the assemblies be dictated by the measure author.