IT security blocker with static linking

[modelica-trac-importer]

Reported by rfranke on 18 Dec 2014 10:31 UTC The FMI 2.0 spec, section 2.3 FMU Distribution, states:

Dynamic link libraries must include all referenced resources that are not available on a standard target machine [for example DLLs on Windows machines must be built with option “MT” to include the run-time environment of VisualStudio in the DLL, and not use the option “MD” where this is not the case].

This makes binary model export convenient but unsafe, i.e. unapplicable to industries. The problem is that the runtime environment is subject to changes due to security updates. See e.g. https://technet.microsoft.com/en-us/library/security/ms11-025.aspx. Or think of the Heartbleed bug (http://en.wikipedia.org/wiki/Heartbleed).

If the DLL of the FMU includes the runtime environment statically, then possible security wholes remain in the FMU if the overall system is updated. Such FMUs could not be installed in critical environments, like power production. I cannot imagine that other target industries for FMUs, like automotive or aerospace, are less sensitive regarding IT security.

This is why it is proposed to change the FMI 2.0 specification as follows:

If a binary FMU uses system resources that are not available on a standard target machine, then these resources must be packaged together with the FMU into the respective binaries folder. Examples for such resources are a special XML parser or the run-time environment of a new version of Visual Studio that is not present in older versions of Windows per default.

Dynamic link libraries must not include external system resources statically [for example DLLs on Windows machines must be built with option “MD” to not include the run-time environment of VisualStudio in the DLL, and not use the option “MT” where this is the case]. This is because the system resources are subject to continuous updates in the case of detected security issues.

---

Migrated-From: https://trac.fmi-standard.org/ticket/313

[modelica-trac-importer]

Comment by andreas.junghanns on 18 Dec 2014 11:37 UTC While the thread you talk about exists, it is usually much reduced in industrial settings where managed PCs use virus and malware protection, sit behind well guarded firewalls and users don't generally visit "untrusted sites".

Compiling with /MD will require the installation of redistribution packages. Those will often not be auto-updated in managed environments. If you pack the (presumably unsafe) DLLs in the FMU, what have you gained?

I am speaking from over 10 years of experience of building, distributing, exchanging and running binary simulation artefacts: /MD requires a large number of things to be set right on target machines, most the end user is neither aware of nor has control over. /MT, albeit wrought with a minimal risk, is by far the more practical (you call it convenient, I'd call it efficient) way to ship mostly self-contained binaries.

But most of all: SxS problems. If you don't know what I am talking about, count yourself lucky. If you do, you are likely on the /MT side of the fence (if not, you might know a trick I don't, then please talk to me!).

[modelica-trac-importer]

Comment by rfranke on 18 Dec 2014 13:53 UTC Here is a nice example about what can happen. It's in German, but to cut a long story short: per spear-pishing into the office network of a steel company, from there to the control network, from there to the control functions, making a blast furnace uncontrollable and unable to shut down, causing high damage: http://www.heise.de/newsticker/meldung/BSI-Sicherheitsbericht-Erfolgreiche-Cyber-Attacke-auf-deutsches-Stahlwerk-2498990.html

If you require an FMU to statically link all runtime libs, then an update becomes practically impossible -- the vendor had to recompile the FMU and export it again to the user.

If the runtime libs are provided as dlls in the binaries folder, then a user has at least the chance to update them. As Windows first looks into the local path, the usability should be the same as if the libs would be linked statically.

In a safety critical environment the respective runtime packages should be installed in a central place of course. I'm quite sure that Microsoft cares about updates of properly installed runtime libs of Visual Studio.

[modelica-trac-importer]

Comment by andreas.junghanns on 18 Dec 2014 16:29 UTC Dynamic linking can influence:

• which version of a DLL is loaded (recursively) depends on the system setup (what is currently installed and even what was once installed!): e.g. it could matter if you had once installed a certain version of Java on your system
• how numeric properties of the CPU/FPU are set depends on which DLLs are loaded into the process context: some versions of DLLs set the CPU/FPU behaviour differently than others
• what other versions of DLLs have been loaded prior into the same process context has an influence on how the system behaves: Other FMUs might have already loaded certain versions of DLLs that your FMU might also want to load
• how the system path is changed or environment variables are changed depends on other DLLs being (indirectly) loaded
• different versions of runtime DLLs might influence, e.g. precision of mathematical functions
• compiling with new versions of a given DLL and then running on a system with an old version might lead to certain functions not being available at all with random consequences
• ...

In short: If you want to guarantee that an FMU computes *exactly* the same way as you tested it, static linking is the only way I know.

C-Code-based FMUs, where you can compile every time you simulate the system also fixes your security concern, without changing the standard, right?

[modelica-trac-importer]

Comment by rfranke on 18 Dec 2014 19:27 UTC Of course C-Code FMUs avoid the reported problem with binary FMUs. Nevertheless binary FMUs are needed because (a) a C compiler is generally not present on a default system, in particular under Windows, and (b) tool and FMU vendors may have harder restrictions on C-Code export than on binary export.

I think there finds use cases for both: static linking and dynamic linking. This is why the FMI specification should allow both. Static linking improves the reproducibility of simulation results subject to changing execution environments. Dynamic linking improves IT security.

It would be a nightmare in a safety critical system if different versions of DLLs with different behaviours would be loaded basically by chance, as you describe. I can imagine such a situation on an R&D PC after lot of trying out, installing and uninstalling different softwares. In a safety critical system you would have a predefined and reproducible installation procedure. Each dll should only find once in the system at its predefined place.

Here is another proposal for the reformulation of:

Dynamic link libraries must include all referenced resources that are not available on a standard target machine [for example DLLs on Windows machines must be built with option “MT” to include the run-time environment of VisualStudio in the DLL, and not use the option “MD” where this is not the case].

into:

Dynamic link libraries can either be linked statically, i.e. include all referenced resources that are not available on a standard target machine [for example DLLs on Windows machines can be built with option “MT” to include the run-time environment of VisualStudio in the DLL, as opposed to the option “MD” where this is not the case]. Alternatively they can be linked dynamically, i.e. only reference the required resources. In the latter case the referenced recourses must be documented and made available by the vendor along with the FMU [for example the runtime environment of the used version of Visual Studio].

[Static linking improves the reproducibility of simulation results subject to changing execution environments. Moreover it avoids the need for the installation of additional resources on the target machine. Dynamic linking is appropriate if the user of a binary FMU must be able to change the execution environment, e.g. to apply security updates. Moreover dynamic linking reduces the computer requirements due to re-use of dynamically loaded resources.]

[modelica-trac-importer]

Comment by rfranke on 19 Dec 2014 07:43 UTC Here are two links that motivate that dynamic linking must at least be allowed optionally:

Microsoft about deployment, static linking, security volnuerabilites: http://msdn.microsoft.com/en-us/library/vstudio/dd293574%28v=vs.110%29.aspx

Ulrich Drepper, a former maintainer of the Linux runtime lib: http://www.akkadia.org/drepper/no_static_linking.html

[modelica-trac-importer]

Comment by peter.nilsson on 19 Dec 2014 09:24 UTC A note about the Linux case. As far as I remember, the motivation for requiring inclusion of all referenced resources came from issues on Windows. Linux however, was somewhat neglected in the discussion and unless people have experienced the same issues as in Windows, this requirement for Linux should be dropped. First, on Linux libraries often only come as shared objects, making static linking not even possible. For the thus only remaining option of dynamic linking, the dependancy tree is often extensive, which would require lots of shared objects attached to the FMU to get all version dependencies right.

[modelica-trac-importer]

Comment by rfranke on 19 Dec 2014 10:26 UTC This could be a compromise to get things right under Linux at least. Would it be thinkable to generate a dependency tree of loaded shared objects and include this into the respective binaries folder?

[modelica-trac-importer]

Comment by rfranke on 19 Dec 2014 20:02 UTC Here is a new version that relaxes the need for documentation and provision of dependencies. Instead the information already present in the exported binary code is exploited (see also https://trac.modelica.org/fmi/ticket/302#comment:15):

Dynamic link libraries can either be linked statically, i.e., include all referenced resources that are not available on a standard target machine, or dynamically, i.e., only reference the required resources [for example DLLs on Windows machines can be built with option “MT” to include the run-time environment of VisualStudio in the DLL, as opposed to the option “MD” where this is not the case].

[Static linking improves the reproducibility of simulation results subject to changing execution environments. Moreover it avoids the need for the installation of additional resources on the target machine. Dynamic linking is appropriate if the user of a binary FMU must be able to change the execution environment, e.g., to apply security updates. Moreover dynamic linking reduces the computer requirements due to re-use of dynamically loaded resources.]

[modelica-trac-importer]

Comment by torstenblochwitz on 10 Feb 2015 13:17 UTC FMI Meeting: We propose to use text from comment 8.

We should add a statement to the FMI Cross Check rules that enforce static linking for the provided FMUs or including all depending libraries.

[modelica-trac-importer]

Comment by cbertsch on 1 Jun 2018 13:37 UTC Shall we allow in 3.0 also dynamic linking? Will there be problems if we would allow mixed statical and dynamical linking? (--> DLL hell problem)

[modelica-trac-importer]

Comment by cbertsch on 11 Jun 2018 09:49 UTC (FCP Alignment Meeting) There have been good reasons for static linking w.r.t. to portability. It is proposed that the FMU shall self-contained. Dynamically referenced DLLs shall be contained in the FMU. Best location would be the platform dependent binaries folder.

It is proposed to provide an URI to the root directory and that the complete ZIP-File has to be unpacked. (Could be optional for other platforms). Alternatively provide two paths to binaries and ressources Not backwards compatible.

Foreseen for FMI 3.0, a separate ticket for clarifications in 2.0.1 will be created.

[modelica-trac-importer]

Comment by cbertsch on 18 Jun 2018 09:12 UTC For clarification in 2.0.1 see #438.

Similar as clarifications for Source Code FMUs in FCP_003, it would be good, that dependencies on external ressources are declared in the modeldescription.xml, so that the importing tool can display it to the user and perhaps could generate a meaningful error message.

For each dependency a string should be contained in the xml.

[modelica-trac-importer]

Modified by cbertsch on 18 Jun 2018 10:14 UTC

[chrbertsch]

Can we close this ticket?

Similar as clarifications for Source Code FMUs in FCP_003, it would be good, that dependencies on external ressources are declared in the modeldescription.xml, so that the importing tool can display it to the user and perhaps could generate a meaningful error message.

For each dependency a string should be contained in the xml.

In the Build Configuration https://fmi-standard.org/docs/3.0-dev/#_definition_of_source_code_buildconfiguration we can define (external) library elements required to link the model binary.