Posted on 11/20/2017 9:43:38 PM PST by dayglored
The way Microsoft patched a recent security bug has made several 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.
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.
"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.
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.
There are 10 kinds of people in the world. Those who understand binary, and those who do not.
But now M$ will end up with crap code...oh wait...
I knew my daughter would end up doing programming the day she asked to get a t-shirt with that motto on it. She was 8. And she earned her BS in CompSci this past year. Chip off the old block, she is. :-)
Patching a binary doesn't necessarily give you bad code.
The legendary spacecraft programmers at JPL patched binary code in interplanetary spacecraft, literally "on the fly", decades ago and for all I know they still do. And not just fixing bugs found after launch -- sometimes they add or modify a flight function to take advantage of something they learned earlier in the flight.
The awesome aspect is that they had to send the changes by radio, taking minutes or even hours to get there, and then they would pray that the changes worked. Because if they didn't, they might crash or silence a bird worth hundreds of millions of dollars.
They probably have the source code, just no one who can follow all the tricks and gimmicks the original programmers used then tweaked over time as newer versions of the OS and newer hardware eliminated the need for such things.
I would say that is highly unlikely, because in order to do a binary patch they would have to deconstruct all of those tricks and gimmicks at assembler level—without decent labels in the code segment or data names in the dseg—and that would be a great deal more difficult than figuring it out from the source, however badly written (even if the original source was x86 assembler itself...)
Taking it down to assembly level would make it easier to read than a lot of legacy code.
What the Hell are you people talking about? All I want is for my putter to start up so I can get to FR!
Happened to me a couple of times on Excel macros that I myself had built or modified to create custom reports from a database. It is embarrassing not to have created a log showing steps or rationale. Relying on memory as one gets older and closer to retirement was just sloppy and complicated the needed continuity training of my successor.
used to do this for NCR back in the day. it is indeed an art.
Many of us older guys are in that same state...
Oh wait, you meant computer...
:-)
I seem to remember using "REM" to denote 'Remarks/comments' explaining the purpose of the previous line of code. I was going to say that "REM is not only kindness to those who will later work on your code, it is also your friend!", however, I can't find anything online to confirm that.
(it has been SO LONG since I worked on even a pitifully small bit of code.... REM is all I remember on this subject!)
[my mind is a 10mb hard drive in my 8088 computer which has not been defragged in 70 years...)
Hopefully they lost source code to PowerPoint.
There should be a few thousand teenagers in basements in Romania who would be willing to dis-assemble the code for them.
One can only dream...
There are, no doubt about it.
“Can you run that report that someone ran for me in 2004?”
“Do you have a report name for it?”
“No, it was 13 years ago!”
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.