How a recent Office patch was done in a very unusual way

A recent security patch for Microsoft Office was done an unusual way, suggesting that there’s something a bit strange happening in the development team.

Last week we told you about a 17 year old bug in the Equation Editor part of Office.  Microsoft fixed the security hole and a few others besides.  The way they did it is raising eyebrows.

It seems Microsoft edited the hackable EQNEDT32.EXE file directly instead of making a new version from the source.

Gross Oversimplification

Normally, developers have the source code for a program.  That’s the text version of the code that (trained) humans can read plus comments and explanations.

That source code is then ‘compiled’ into a program which is distributed.  The program (for example .exe) runs much faster than running directly from the source code.

Fixing a security bug usually involves editing the source code then compiling and sending out a new version of the program.  That’s what Microsoft usually does to fix a security bug, add or change a feature.

It’s possible to edit the compiled program but it’s very difficult.  It’s written in machine language and is very precise. Here’s the sort of thing you’re looking at.

Source:  0Patch

Adding to the difficulty is the lack of documentation.  The source code will include a lot of comments and details to explain the program, how it works and why it’s coded in a particular way.

The overall size of the program has to remain exactly the same.  One wrong character and the whole thing breaks.

Editing the executable is a developers last resort and a hard road to go.

Binary Patch

But that’s what Microsoft did to fix this bug; a ‘binary patch’.  They delved into the machine code of EQNEDT32.EXE to directly block the security hole and a few other problems as well.

The 0Patch team discovered all this in an extensive analysis Did Microsoft Just Manually Patch Their Equation Editor Executable? Why Yes, Yes They Did.

Whomever did the patching, did a great job on a tight deadline.  If Microsoft gives out bonuses, those people deserve one.

They not only fixed the known security hole they found some other problems and fixed them too. Also changed a programing flag to make future hacking harder.

One function was made shorter and needed padding with blanks to retain the program size.

How do we know?  Each time a program is created (compiled) it’s slightly different.  Experts can tell the difference between a recompiled program and an edited one.

Why?

Why did Microsoft do these fixes in such a hard way?  They aren’t talking but there’s one very likely reason …

They’ve lost the original source code!

It’s possible that the source code for EQNEDT32.EXE is either lost or buried so deep in Redmond’s backups that it’s difficult to find.

That might seem improbable to outsiders but anyone who has worked on software over time has struck the problem of missing source code. The Y2K bug fixes revealed many cases of programs that had worked very well for many years and were taken for granted by the IT department.  When Y2K questions arose, there was no source code to help identify any problems.  Whole programs had to be re-engineered and re-written.

Aside from admiration for the fixers of EQNEDT32.EXE it’s a lesson that even the biggest software makers on the planet can lose the keys to their wares.

Anything else?

Presumably (hopefully) Microsoft isn’t arrogant enough to think this was an isolated incident.

A ‘softie should be on the job of tracking down every piece of Microsoft Office, no matter how old or insignificant, to make sure they have the source code too.

Want More?

Office Watch has the latest news and tips about Microsoft Office.  Delivered once a week.