Author Topic: Microsoft Appears to Have Lost the Source Code of an Office Component  (Read 165 times)

Online javajolt

  • Administrator
  • Hero Member
  • *****
  • Posts: 35126
  • Gender: Male
  • I Do Windows
    • windows10newsinfo.com
The way Microsoft patched a recent security bug has made security and software experts believe the company might have lost the source code to one of its Office components.

Experts reached this conclusion this week after Microsoft patched a security vulnerability tracked as CVE-2017-11882 that affected EQNEDT32.EXE — the equation editor that was included with the Microsoft Office suite until 2007.

While Microsoft has replaced the old EQNEDT32.EXE component with a new one in 2007, the older file is still included with all Office installations to allow users to load and edit equations created with the old component.

The way Microsoft patched a recent bug raised some eyebrows

Researchers at cyber-security firm Embedi discovered a flaw in this component over the summer. The bug got a lot of media attention because it allowed silent attacks on all Microsoft Office and Windows versions released in the past 17 years with no user interaction.

While most security experts looked at the Embedi 20-page report for details on the bug, one particular company looked at the way Microsoft patched the bug in Office.

Experts from 0patch — who run a platform for instantly distributing, applying, and removing microscopic binary patches — noticed that the patched EQNEDT32.EXE file was almost identical to the old one.

Microsoft manually edited a binary

"Have you ever met a C/C   compiler that would put all functions in a 500  KB executable on exactly the same address in the module after rebuilding a modified source code, especially when these modifications changed the amount of code in several functions?," 0patch experts asked rhetorically.

When programmers modify source code and compile a new binary, the compiler modifies the memory addresses of functions when the binary is compiled. This creates a slightly distinct binary every time.

The only way the new EQNEDT32.EXE stayed so similar to its previous version was if Microsoft engineers manually edited the binary itself.

A company like Microsoft that has solid and complex software development and security practices in place would never deem manually binary editing as acceptable.

The only way this happened is if Microsoft somehow lost the source code of a long forgotten Office component.

Embedi researchers pointed out that the component's age is what attracted them to hunt for bugs inside it in the first place.

"The component was compiled on 11/9/2000," the Embedi team pointed out. "Without any further recompilation, it was used in the following version of Microsoft Office. It seems that the component was developed by Design Science Inc. However, later the respective rights were purchased by Microsoft."

Somewhat weird that a component that shipped with Office in the last 17 years did not receive one single update.

Praises to whoever manually patched EQNEDT32.EXE

Manually editing executables to alter a binary's behavior is considered a low-level hack, one that usually causes more problems than it solves. Developers that engage in such tactics usually risk corrupting the entire binary. According to 0patch, the EQNEDT32.EXE patching was a work of art.

The CVE-2017-11882 vulnerability happened because the EQNEDT32.EXE would allocate a fixed size of memory and load a font name inside. If the font name was too long, it would trigger a buffer overflow and allow attackers to execute malicious code.

0patch says it found fixes for this problem —checks to verify and truncate the font's name— but also other modifications in unrelated parts of the binary.

"There are six such length checks in two modified functions, and since they don't seem to be related to fixing CVE-2017-11882, we believe that Microsoft noticed some additional attack vectors that could also cause a buffer overflow and decided to proactively patch them," 0patch said.

In addition, Microsoft optimized other functions, and when the code modifications resulted in smaller functions, Microsoft added padding bits to avoid not messing the arrangement of other nearby functions.

Such efforts to avoid not ruining the EQNEDT32.EXE binary are time-consuming, and no sane developer would have taken this route if he still had access to the source code. Furthermore, Microsoft also modified the binary's version number also by manually editing the binary.

All the clues point to the conclusion that Microsoft lost access to the EQNEDT32.EXE source code, which if you think about the amount of software the company has managed in the last 42 years, it's a wonder it did not happen a few more times before.

"Maintaining a software product in its binary form instead of rebuilding it from modified source code is hard. We can only speculate as to why Microsoft used the binary patching approach, but being binary patchers ourselves we think they did a stellar job," the 0patch team said.

source