Durch Zufall bin ich kürzlich auf den englisch sprachigen Blog Post von Vjeko gestoßen, bei dem es um die Sicherheit von Microsoft Dynamics NAV FOB-Dateien geht. Da ich das Thema sehr interessant finde und noch keinen deutschen Post dazu finden konnte, wollte ich dies hier mit euch teilen. Ich denke wenn ihr dies gelesen habt, werdet ihr sensibler mit fremden FOB-Dateien umgehen die ihr in eure Datenbank importiert. (Betrifft nur Drei-Tier Architektur / RTC Client)

C/AL VS. C# Code

Seit der Einführung der Drei-Tier Architektur mit Microsoft Dynamics NAV 2009, wird der von euch erzeugte C/AL Code nicht mehr direkt von NAV interpretiert, sondern dient nur noch der Entwicklung. Speichert ihr ein C/AL Objekt ab und kompiliert es gleichzeitig, wird der Code intern in C# Code gewandelt und der C/AL Code interessiert von nun niemanden mehr, es sei denn ihr bearbeitet das Objekt wieder. Um es kurz zu machen, der C/AL Compiler übersetzt lediglich C/AL in C# Code.

Der C/AL und C# Code wird nun in der Tabelle 2000000071 (Object Metadata) gespeichert. Diese Tabelle enthält zwei BLOB Felder: „User Code“ und „User AL Code“. Das Feld „User AL Code“ beinhaltet den von euch erzeugten C/AL Code, „User Code“ den übersetzten C# Code. So lange das Objekt nun kompiliert ist, interessiert der Code in „User AL Code“ zur Laufzeit niemanden mehr. Wer mehr über die interne Verarbeitung des Codes lernen möchte, sollte sich einen weiteren Post von Vjeko zu Gemüte führen.

Unsichtbaren C# Code in FOB-Datei injizieren

Kommen wir nun zu dem eigentlichen Problem. Wie oben beschrieben, interessiert der C/AL Code zur Laufzeit nicht mehr, so lange das Objekt kompiliert ist. Importiert ihr euch also ein fremdes FOB-Objekt in eure Datenbank, wird weiterhin nur der C# Code des Objektes ausgeführt, der aber manipuliert worden sein kann ohne dass ihr es auf den ersten Blick sehen könnt.

Anbei habe ich ein Test-Objekt von Vjeko hochgeladen, welches euch das Problem demonstriert. Importiert das Objekt (Codeunit 87654) in eure Test-Datenbank und designed es. Ihr werdet auf den ersten Blick nur folgenden C/AL Code sehen:

Wenn ihr das Objekt nun wieder verlasst (ohne es zu kompilieren!) und anschließend startet, geht ihr davon aus dass ihr lediglich eine Messagebox mit dem Inhalt „Hello World!“ angezeigt bekommt. Was ihr seht ist aber deutlich mehr, und spätestens jetzt solltet ihr keinen FOBs mehr trauen 🙂

Was ist hier passiert?

Wir haben also eine Codeunit die mehr tut als sie sollte bzw. mehr als wir auf den ersten Blick sehen. Hier wurde der Inhalt des Feldes „User Code“ in der oben genannten Tabelle 2000000071 gegen einen anderen – zuvor von C/AL in C# übersetzten Code – ausgetauscht. So lange das Objekt nun nicht erneut kompiliert wird, gibt es einen Unterschied zwischen C/AL und C# Code und wie wir oben gelernt haben, wird nur der C# Code vom Client ausgeführt und nur der C/AL Code im Designer sichtbar gemacht.

Was lernen wir daraus?

Solltet ihr fremde FOB-Objekte nutzen, kompiliert sie nach dem Importieren einmal oder nutzt TXT-Dateien für den Austausch. Diese müssen im Anschluss an den Import zunächst kompiliert werden.

Dieser Beitrag soll nicht als Anleitung dienen damit ihr infizierte FOB-Dateien verbreiten könnt, sondern soll euch lediglich vor der Nutzung fremder FOBs warnen und sensibilisieren!