Hat Microsoft Zugriff auf Teile des Office-Quellcodes verloren?

Nach den letzten Patches des Office-Formeleditors ist die Spekulation aufgekommen, ob Microsoft möglicherweise den Zugriff auf Teile seines Office-Quellcodes verloren hat. Hier ein paar Informationen.

Im Formeleditor EQNEDT32.EXE, der bis 2007 in Microsoft-Office enthalten ist, gab es eine Sicherheitslücke CVE-2017-11882, die beim November 2017-Patchday mit geschlossen wurde (ich hatte es im Blog-Beitrag Microsoft Office Sicherheitsupdates (14. November 2017) erwähnt).

Die Sicherheitslücke wurde im Sommer von Forschern des Cybersicherheitsunternehmens Embedi entdeckt und erregte Aufmerksamkeit in den Medien, weil sie stille Angriffe auf alle Microsoft Office- und Windows-Versionen der letzten 17 Jahre ohne Benutzerinteraktion erlaubte.

Der alte Formeleditor ist noch da

Im Jahr 2007 wurde zwar ein neuer Formeleditor in Microsoft Office eingeführt. Aber die Dateien des alten Formeleditors EQNEDT32.EXE sind nach wie vor in allen Office-Versionen enthalten. Benutzer können also weiter auf den alten Formeleditor zugreifen, um Gleichungen zu editieren.

Während Microsoft die alte Komponente EQNEDT32.EXE im Jahr 2007 durch eine neue Komponente ersetzt hat, ist die ältere Datei immer noch in allen Office-Installationen enthalten, damit Benutzer die mit der alten Komponente erstellten Gleichungen laden und bearbeiten können.

Merkwürdige Patcherei

Nun haben sich Sicherheitsspezialisten wohl die Umstände für den Patch dieser Sicherheitslücke angesehen und kamen aus dem Staunen nicht mehr heraus, wie Bleeping Computer hier schreibt.

Während die meisten Sicherheitsexperten sich den 20-seitigen Bericht von Embedi zu den Details des Fehlers anschauten, interessierten sich andere Fachleute für den Patch an sich. Die Experten von 0patch hatte ich hier im Blog ja schon häufiger erwähnt. Die Firma 0patch entwickelt Patches gegen Zero-Day-Exploits. Den Fachleuten von 0patch ist nun aufgefallen, dass die gepatchte Datei EQNEDT32.EXE fast identisch mit der alten Dateiversion war.

Das ist äußerst ungewöhnlich, wenn man weiß, wie es normalerweise abläuft. Wird ein geänderter Quellcode nach vielen Jahren durch einen Compiler neu übersetzt, ist es äußerst unwahrscheinlich, dass alle Funktionen in einer 500 KB-Programmdatei an exakt die gleiche Stelle gespeichert werden. Die binäre Signatur neu übersetzter Programme weicht nach Änderungen des Quellcodes immer signifikant vom Vorgänger ab.

Für die Experten von 0patch gibt es nur eine logische Erklärung, warum die neue Version der EQNEDT32. EXE der vorherigen Version so ähnlich ist: Die Microsoft-Entwickler müssen die Binärdatei selbst manuell editiert haben. Für eine Firma wie Microsoft, die eine Versionspflege und Codeverwaltung hat, dürfte aber das manuelle herumfummeln am Binärcode ein no go sein.

Und es gibt noch eine Merkwürdigkeit. Der Formeleditor meldet sich mit folgendem About-Dialogfeld. Dieses zeigt, dass das Programm zuletzt 2000 übersetzt wurde. Etwas, was normalerweise nicht vorkommt, wenn ein Quellcode angepasst und neu übersetzt wird.

(Quelle: Embedi)

Das Modul wurde laut About-Dialogfeld zudem von Design Science Inc. erstellt. Microsoft hat später die Rechte an diesem Formeleditor von Design Science Inc. erworben. Halten wir also fest: Im Formeleditor gab es seit 17 Jahren einen Fehler, und das Teil wurde niemals seit dieser Zeit aktualisiert, sondern 2007 durch einen neuen Formeleditor ersetzt.

Das lässt nur einen Schluss zu: Microsoft hat irgendwie den Zugriff auf den Quellcode des alten Formeleditors verloren. Oder noch schlimmer: Vermutlich haben die Leute bei Microsoft niemals den Quellcode des Formeleditors besessen. Im Bleeping Computer-Artikel lassen sich noch einige Details nachlesen.

Ich bin ja schon ein paar Jährchen im Geschäft und halte das geschilderte Szenario für durchaus plausibel. Um das Jahr 2000 herum kam ich mit einem jungen Deutschen, der in den USA lebte, in Kontakt. Damals ging es um einen Microsoft-Debugger für Scripting. Der deutsche Entwickler wollte eine Schnittstelle für eine eigene Software aufsetzen, die den Debugger nutzte. Als er den Quellcode des Microsoft Debuggers sah, beschloss er, seinen eigenen Debugger zu schreiben. Ich erinnere mich nicht mehr im Detail – aber es war wohl so, dass das Zeugs undokumentiert, unvollständig und fehlerhaft war und seinerzeit von keinem bei Microsoft mehr verstanden wurde. Nachdem einige Leute bei Microsoft in den letzten Jahren gegangen (worden) sind, könnte ein ähnliches Szenario zutreffen. Lässt Raum für viel Phantasie, wie es mit anderen Produkten bestellt ist und würde mir auch einiges erklären …