Microsoft engineers appear to have manually patched a 17 year-old vulnerability in Office, instead of altering the source code of the vulnerable component, ACROS Security researchers say.
Tracked as CVE-2017-11882, the vulnerability was addressed with a fixed release on November 14 as part of Microsoft’s Patch Tuesday security updates. The issue was discovered by Embedi security researchers in the Microsoft Equation Editor (EQNEDT32.EXE), a tool that remained unchanged in the Office suite since November 9, 2000.
While analyzing the patched version of the file, the researchers from ACROS Security’s 0patch Team discovered that it was nearly identical with the original file, although the new compilation date is 2017.8.14.0.
This would not be possible if Microsoft made the necessary corrections to the source code and then re-built the binary. However, manually patching the binary executable makes this possible, and this is what the researchers believe happened with the Equation Editor.
“Really, quite literally, some pretty skilled Microsoft employee or contractor reverse engineered our friend EQNEDT32.EXE, located the flawed code, and corrected it by manually overwriting existing instructions with better ones (making sure to only use the space previously occupied by original instructions),” Mitja Kolsek from the 0patch Team explains.
Microsoft declined to comment on how the vulnerability was addressed.
Proof of that can be easily found when comparing the original and the patched file versions. No C/C++ compiler “would put all functions in a 500+ KB executable on exactly the same address in the module after rebuilding a modified source code,” the researcher notes.
BinDiff results between the two files show that all EA primary values are identical to EA secondary values of matched functions and that even the patched functions have the same address in both EQNEDT32.EXE versions.
The vulnerability discovered by Embedi consisted of the Equation Editor not checking whether the destination buffer was large enough for the user-supplied string. Thus, if the font name provided through the Equation object has a name long enough, it could cause a buffer overflow.
An additional parameter added to this function now specifies the destination buffer length, which the original logic of the character-copying loop now ends when the destination buffer length is reached as well, to prevent buffer overflow.
“In addition, the copied string in the destination buffer is zero-terminated after copying, in case the destination buffer length was reached (which would leave the string unterminated),” Kolsek notes.
According to the researcher, in addition to adding said check for buffer length, the engineers who patched the function also managed to make it 14 bytes shorter. On top of that, it appears that the engineers patched other functions in the component as well, most probably because they discovered additional vulnerabilities and decided to resolve them too.
Two functions in the patched version now have boundary checks injected right before inlined memcpy operations. According to Kolsek, the engineers who patched the Equation Editor used only a single instruction (instead of two) for implementing the checks, thus leaving the code logically identical, but also freeing up space for injecting the check and for zero-terminating the copied string.
“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,” the researcher points out.
Kolsek also notes that patching a software product in its binary form instead of rebuilding it from modified source code is very difficult, but that Microsoft’s engineers did a stellar job when fixing the Equation Editor. The component might be old, but it’s still required to ensure compatibility with documents that contain equations in the old format.
The only question that remains unanswered is why Microsoft chose to maintain the component in its binary form instead of altering the source code and recompiling it instead. Some suggest that the company might have lost the component’s source code.
We contacted Microsoft for a comment on this and will update the article as soon as we hear back.
*Updated reflecting that Microsoft has declined to comment