What about Dynamics NAV and Meltdown/Spectre?

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.

Dynamics NAV2013 and NAV2013R2 are no longer supported

CU51 for 2013R2 and CU58 for NAV2013 will be the last updates. both versions are no longer under support.

“Cumulative Update 51 for Microsoft Dynamics NAV 2013 R2 will be the last release for Microsoft Dynamics NAV 2013 R2 as it by January 9, 2018 will be out of mainstream support period.”

Cumulative Update 51 for Microsoft Dynamics NAV 2013 R2 has been released

https://pbs.twimg.com/profile_images/676792894813024256/N7zqcEMg.png

If you’re using these versions, you should consider to upgrade to a new release, either by a real update, or just during a runtime upgrade.

 

NAV2018 Getting rid of the Text 1024 limitation

With NAV2015 we got Text variable with length only limited by DotNet (1 billions characters). But the standard NAV application still had several 1024  characters limitation, one of them was the handling of filtering on dimension values.

Filtering on Dimension Values

In blog post there is an example with a loop. Inside the loop, a function returning 1024 characters of a filter set using the GetNextDimSetFilterChunk function in codeunit 408.

When trying to compile the above code with NAV2018, the GetNextDimSetFilterChunk function is no longer present and you’ll get a compile error.

Microsoft has remove that function and you can replace the entire loop with just:

Filter := DimensionMgt.GetDimSetFilter();

Easy, peasy :I