Mika saw that t-shirt and thought it was a discriminatory dog whistle
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.
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.
...
I worked at a huge computer company in operating systems, and there were a couple of guys who would have preferred to fix every defect this way.
Microsoft is now an Indian owned and operated company. The idiocy of Indian programmers is well known in the software industry.
Yeah, especially if there are 2.2E145 versions of the source code, as in Microbloat stuff.
One of my students has a t-shirt that reads: “!FALSE is funny because it is true.
I used that yesterday in a text to a buddy having computer problems. It never gets old.
Mika saw that t-shirt and thought it was a discriminatory dog whistle
This happened recently with the New Horizons Pluto probe. They started the process to wake up the probe and make minor course corrections about 2 weeks before the one-time-only flyby. The probe was unresponsive. They determined that most of the code had been corrupted or loast.
They had to reproduce, compile and send the code again in about 10 days. A process that had taken them years to complete before launch...3 years before.
They got it done just in time with a 36 hours to spare. The results were spectacular. One helluva good job.
Not really, since you would have no meaningful labels of any kind, and the optimized assembler produced by most compilers turns even very well written code into what appears to be spaghetti to humans.
-PJ
wrong.
If the code has not changed since then, and the change was simple enough, the binary produced could be nearly identical to the original.
like if you change a “+” sign in an equation to a “-” and then compile using the exact same build environment, you could get a binary that differed in just a couple of bytes.
I strongly suspect that they have the entire build environment available so they would have have to recreate it and THEN make this simple change, otherwise you’d have to do a complete integration test.
I would not doubt that the computer to build this exists virtually, with all the source code.
From the article:
"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.Those aren't small changes that would cause "a couple of bytes" of difference. Adding length tests requires additional code not present in the original binary.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.
And padding out an optimized function so as to not cause relocation of a function after it -- that's a sure sign somebody was editing a binary. Been there, done that. If a function was shrunk, I used the "spare" space to hold a new piece of code that had to be added. But almost always, some amount of padding was required. I would use either 0xFF, or a repeating pattern, so I could quickly identify it should I need to use it later.
Although the article didn't detail this particular trick, another sure sign of a binary patch is the replacement of straight-line instructions with an unconditional jump to a spare area, where the original instructions were copied and then additional instructions (typically a conditional test) added, and finally a jump back to where the unconditional jump had been patched in. No compiler would produce that. Such tricks of the trade are unmistakeable, and my guess is that such artifacts were what prompted the conclusion.
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.