So how about Microsoft Dynamics NAV and the Meltdown and Spectre exploits? This is my analysis so far.
First of all, this is a CPU bug, a bug that enables you to access data from outside your current process, data that is either owned by the kernel or other applications. This means, that if you’re running any piece of non-trusted code on your machine, that code can read anything currently in memory. Passwords and other information is typically encrypted on storage devices but exists in memory as plain data. This is the problem as the Heartbleed exploit (OpenSSL) that enabled to read memory from an SSL process.
To exploit Meltdown or Spectre, you need some control of the binary code running.
In Dynamics NAV code gets executed in 6 different ways:
- C/AL code in the Classic Client. This code gets executed as “P-Code”, an intermediate language. There is no way to control the assembler generated. And between “lines of code” there are several other operations taking place, making exploitation of the CPU very hard.
- Win32 binary as an OCX controller or an Automation Controller called from either the Classic Client or the RTC (With RunOnClient Automation Controller). It is possible to have a Meltdown/Spectre attack inside an OCX or Automation Controller.
- C/AL code in the Service Tier. The C/AL is transcompiled into C# that gets compiled into IL, that gets Just-In-Time compiled into machine language. The code is still interjected with control structure between statements (for debugging etc.) making it quite impossible to control the assembler generated.
- Add-Ins on the Service Tier. An Add-In is a .NET assembly, that can include native code and more. It has the same problem as the Win32 binaries. It is possible to have a Meltdown/Spectre attack from an Add-in.
- Javascript running as Control Add-In in all the clients. There are already several examples of Meltdown/Spectre exploits through Javascript. So a Javascript based Dynamics NAV Control Add-In could carry an exploit. Control Add-Ins can download javascript from external sources (the web) making this the most open attack vector.
- Custom code inside RDLC reports. This code still gets compiled through the entire pipeline making it very hard to control the machine language.generated, but in theory possible on an unpatched system.
So if you are using external code in the form of DLLs (OCX, Automation Controller, Add-In, Control Add-In) there is a technical possibility of hosting an exploit. You need to make sure, that you’re only using external components from vendors that you trust, and that the DLLs you’re running are unmodified. (*)
Microsoft has already patched Windows to prevent exploitation from Meltdown and Spectre, and Intel/AMD are working with hardware vendors to update the firmware. On an up-to-date system, these exploits would not work. If the system is patched, a “NAV born” exploit will not work.
If you’re running NAV on an unpatched system, my suspicion would be that NAV is the least of your problems.
My conclusion so far, Dynamics NAV does not require patching but needs to be running on a patched Windows. This is a good reminder to make sure that you know that code your ERP system is running on.
(*) To be sure, you need to think about protecting against a combined attack. If it’s possible through other exploits to patch the NAV DLL’s on the system, NAV could be hosting a Meltdown/Spectre attack.