The Story Behind a Windows Security Patch Recall

bheer writes "Raymond Chen's blog has always been popular with Win32 developers and those interested in the odd bits of history that contribute to Windows' quirks. In a recent post, he talks about how an error he committed led to the recall of a Windows security patch."

Comments

Re:Awwww, touching....

[misleb]

Heck why not just go all the way an cut them loose?

What the...

[P2PDaemon]

Why are the trolls out in force here? Oh, Microsoft... Nevermind...

If this happened at Apple...

[Jadware]

Raymond Chen would be iFired, or at least told to iRTFM.

The Money Quote

[SixFactor]

You're about to be Slashdotted.
Seriously, it's good to get a glimpse of the interactions in the dev side of MS. It's astonishing that MS even allows this to happen at all. The March 07 Wired had a feature on Channel 9 that humanized the MS organization quite a bit, IMO. It's not just about chair-throwing, marketing hyperbole, and world domination after all... oh wait.

Re:The Money Quote

[snowgirl]

Your sig: Sheep, Sheepdog, or Wolf: Choose.

I choose moof!

Fascinating

[wbean]

This is fascinating. The system for exiting a process is so complicated that a lot of implementations fail. In fact, it's so complicated that even Microsoft can't get it right. Sounds like an unbounded loop to me.

Re:Fascinating

[Anonymous Coward]

Sounds like an unbounded loop to me.

That's quite an appropriate analogy. If you RTFA, you would know that the loop in question is designed to be bounded by a guard variable/event, but they had already terminated the thread that sets the guard to the state that allows the loop to terminate.

The root cause of the hang is that most programmers are not really aware of the states involved at process termination, so they assume invalid things about the DLL process termination event -- namely that it's okay to wait for something that may have been locked/entered by a child thread.

p.s. To the sibling AC, I know you were going for funny, but they're not trying to solve the haling problem.

Re:Fascinating

[Timesprout]

Raymond has touched on the complexity of their software before and noted that oftentimes the complexity was not acually a product of the fuctionality but due to fixes, patches and additions to the code over time. To his credit he has in the past admitted that issues similar to this one were introduced because the core problem ie loading faulty shell extensions was not addressed directly for reasons of time/money/too scared to touch it/whatever and the hacks and workarounds only served to pointlessly bloat the complexity of the whole system. It's also worth noting that this complexity creep was not entirely due to MS. They had 10s of millions users with god knows how many applications which the MS dev teams struggled to support with backwards compatability etc. Raymond has admitted in the past that specific checks were put in the OS for certain applications to keep them functioning. Nice if you are a third party developer but just asking for trouble for your OS.

Re:Fascinating

[Quantam]

You should read The Old New Thing site (or the book by the same name, which is basically just a cleaned up and edited version of everything on the site). For those not familiar with him, Raymond Chen is THE backward compatibility guy at MS. He and his minions have to find all the badly programmed programs that break when Windows improvements are ready to ship (for examples of just how bad some of these programs are, read the site; little things like walking the stack from a window callback function to find some data value used earlier, etc.), and figure out kludges to make them still work despite improvements to the OS. Not surprisingly, he has a massive amount of knowledge to share about how Windows has become so complex and so warped.

He also is there to give advice on things NOT to do in coding (and yes, he does indeed talk about bad things MS employees have done, although he never refers to exactly where he encountered a particular bad thing he discusses).

Re:Fascinating

[Chops]

It's not just that -- there's a whole little gang of design flaws responsible here, each of them egging the others on like adolescent boys with dangerous tools at their disposal. To all of the people saying, "well, it has to be that way because Microsoft has 5 billion trillion gazillion apps to support and they're not responsible for third party blah blah blah," I say this: No. Shut up. Linux vendors release updates for a body of software that is a massive superset of what Windows Update covers, often with a tiny fraction of the QA manpower, and problems like this are still quite rare. Why? Well, let's take a look at design flaws that caused the vulnerability Chen was solving:

• Windows handles OS extensions by loading DLLs into Explorer's address space, instead of introducing a layer of separation and interacting with a separate process (a design which would have allowed graceful handling of arbitrary errors in the extension).
• It's apparently easy to accidentally construct code which Explorer believes is a usable shell extension, and likewise impossible to add checks to Explorer such that it will only use, as a shell extension, something which was deliberately intended to be a shell extension. Stop and think about that for a long, long second. That's shockingly shitty design even for Microsoft. Chen blames the application programmers (saying, "lots of people mess up IUnknown::QueryInterface" and linking to a page containing what appears to be an excerpt from the Nag Hammadi scriptures in the original Coptic), instead of realizing that if professional programmers show a consistent pattern of making particular mistakes interacting with an interface, the interface is probably poorly designed.
• As you mention, this seems like a design flaw in the implementation of threading, DLL handling, and process exit. The same construct in Linux does not hang -- it waits until the thread terminates, and then exits normally:

  #include <pthread.h>
  #include <stdio.h>
  #include <stdlib.h>
  
  volatile int stop_now;
  
  void stop()
  {
  printf("Stopping, sort of.\n");
  while(!stop_now);
  printf("All done.\n");
  }
  
  void *start(void *arg)
  {
  sleep(10);
  printf("Deciding to stop.\n");
  stop_now = 1;
  }
  
  int main(int argc, char **argv)
  {
  atexit(stop);
  stop_now = 0;
  
  pthread_t thread;
  pthread_create(&thread, NULL, start, NULL);
  
  exit(0);
  }

I can feel Chen's pain -- it must have been awful trying to botch around the fallout from the first two stupidities, and then getting screwed by the third. I don't think that lets Microsoft off the hook at all, though. The responsibility for the hacked-together, poorly-planned, teetering heap of an OS that they now have to support (at tremendous cost) lies nowhere but at their own metaphorical feet.

An error he committed?

[drinkypoo]

he talks about how an error he committed led to the recall of a Windows security patch.

Okay, he made an error. Why the HELL wasn't it caught in QA? Microsoft wants us to believe that the reason that we have to wait for patches is that they are getting some kind of exhaustive QA. This patch and executable were specifically created to avoid problems with invalid shell extensions. Don't you think that given that fact the thing to do would be to test it with some invalid shell extensions?

This is the reason that Windows admins have to be so much more paranoid about patches than the rest of us. A Windows patch is highly likely to be a big pile of crap that causes your system to not work properly. I think we can all remember certain service packs that broke various versions of Windows NT pretty much completely...

If you can't have confidence that security patches will fix more than they break, how can you have sufficient confidence to even install that vendor's products, let alone count on them for mission-critical applications?

Re:An error he committed?

[NickFitz]

As he points out in his response to the second comment on his blog post, internal testing can't possible cover every single third party shell extension on the planet. (Nor does he try to use that as an excuse for his screw-up.)

Re:An error he committed?

[geekoid]

While Kudos to him for taking responsibility, the QA excuse doesn't seem to fit.

IT was an error hat happened all the time, under its most basic use.

While the global OS QA might be excused for some wierd bug that happens under unforseen circumstance, this wasn't even tested to see if it fixed what it wqas supposed to.

Sounds like sloppy(i.e. none) QA to me.

Re:An error he committed?

[bmajik]

I'm a software tester at Microsoft, although I'm not involved with the Windows team or the security process.

Just so we're clear:

Microsoft is not selling you products that have gone through exhaustive QA, nor are we issuing patches that have gone through exhaustive QA.

The key word here is "exhaustive".

You can imagine that as much as it costs a business when they get a hotfix from us that breaks them, it costs us _at least_ that much in real employee hours (dollars), not to mention the direct and indirect, monetary and non-monetary costs of having to admit that we screwed up a patch.

Software testing cannot tell you how good your product is, only in what ways it doesn't appear to be bad. Every release decision is a _decision_, and its based on necessarily incomplete data put together by imperfect humans with non-infinite time.

A release decision is a culmination of many nested risk/reward tradeoffs. Sometimes, that decision gets made incorrectly, or at least gets made in a way with known or even unknown downsides.

You'll notice that the patch was an interaction problem with an antique 3rd party product. From my time doing admin work on Solaris, IRIX, and Linux machines, I can tell you the big difference between this situation and "those" situations. I never _ran_ 3rd party software on Solaris, IRIX, or Linux (well, I ran 3rd party software on linux all the time, but i just expected it to break anytime i patched anything.. it was a mandatory recompile of any dependant libraries and applications).

I also think your glasses are a little rosy. There were some IRIX patches back in the day that you couldn't back out. Or that wrecked your XFS volumes. I think in every operating system there has been at least one instance of a patch / upgrade / new version that some user opted to back out, because it hurt them and their scenarios more than it helped.

I run very little non-Microsoft software on my windows machines and thus I rarely worry about patches from MS. If you're doing something weird, you need to be more risk averse. IIRC, Microsoft's official recommendation for businesses with critical systems is to install patches in a pre-production environment to ensure compatability with the specific intricacies of your business. You can choose to play fast and loose, but you should be aware that you're making a risk/reward tradeoff decision, based on incomplete data.

Just like we have to do.

Re:An error he committed?

[Quantam]

Guess what? If one shell extension can cause the problem, then another shell extension can likely cause the same problem. He never explains why that would not be true, so there is no reason to assume that it would not be true. Generally speaking, there's more than one way to write a program that does the same thing, and there's more than one way to arrive at the same error condition.

Thank you for making one of the most obvious (and thus pointless) statements of the century (did you know that things fall to the ground when you drop them? I'm completely serious) Yes, you are absolutely correct. In any relatively deterministic system, doing something bad in a predictable way will cause the same failure, predictably. Obviously, as this is deterministic, who is doing said bad thing in said predictable way is irrelevant; thus, multiple things may do the same bad thing with the same bad outcome. The blindingly obvious question this raises is exactly how many things do this. Whether 1 or 2 (or even 10) pieces of hardware do this makes little different if there's 5,000,000 pieces of hardware to test, and you only have the manpower to test 5,000 of them. Would you call testing a patch with merely 5,000 pieces of hardware horribly negligent? If so, I suggest you go work for them, and demonstrate that it's possible to test all 5,000,000 pieces in one month (several times, actually, as there are several patches to check).

There is even a comment which raises a more detailed question about the explanation, which has not yet been answered.

That poster is correct in his last paragraph (and the preceding paragraph, which indicated the problem): it was overlooked because, if it was going to break in this patch, it would have been breaking before this patch, as well; only the timing would have changed. Do you check every morning when you get up to make sure the sky is still blue and the grass is still green (I can smell the jokes coming already)? There are a million ways to do things that MSDN tells you specifically to never ever ever do; do you expect MS to check third-party code for every single one of them?

On one last personal note: Don't try to out-asshole me. You will fail. I'm not exactly proud of that, but you need to pull your head out of your ass before you come after me.

I am hurt that you give me so little credit. I would never attempt to challenge you at something I am so totally and obviously outclassed in. I would be much more concerned if you put me on your friends list.

Re:An error he committed?

[Lars T.]

Yeah, trying to fix a broken registry is SOOO much easier.

Re:An error he committed?

[Blakey Rat]

And the manpower to run it all costs... how much?

Seriously, though, just putting all that equipment in one building would create a zeppelin-hangar-sized building. Finding any specific router or PCI modem would be near impossible. The logistical difficulties of your plan I think would be insurmountable, not even considering the manpower question.

The real point Raymond mentions is that if MS does tons of testing on all the hardware they have available, they get bad press for being slow to release patches. If not, they get bad press for having to recall buggy patches. It's a lose/lose situation for them.

Re:An error he committed?

[Helldesk Hound]

> Okay, he made an error. Why the HELL wasn't it caught in QA? Microsoft
> wants us to believe that the reason that we have to wait for patches
> is that they are getting some kind of exhaustive QA.

M$ doesn't have "QA". It has QC.

Quality Assurance is the fence at the top of the cliff that at each stage prevents faults from arising, and thus from impacting on later stages of development.

Quality Control is the ambulance at the bottom of the cliff that responds to the emergency call once the fault has been discovered.

Most places do not implement QA. They frequently have only the most rudimentary QC.

Given the phenomenal number of security flaws and other bug fixes that have to be applied every month (that's every month since WindowsXP was released six years ago), what type of quality management do you think M$ uses in it's development process?

Re:An error he committed?

[mosch]

So, somebody installed 10.3 on what was either the oldest possible supported laptop, or possibly an unsupported laptop, then a video driver update caused some problems, all of which were fixable by somebody who fully admitted that they don't know OS X, only Unix and Windows.

Obnoxious, sure, but not really different than any other OS. (In fact I have had brand-spanking new Windows hardware that would lose video if I applied WindowsUpdate recommended driver updates.)

I'd have to be pretty stupid to think that any OS is perfect, but I'd have to be even dumber to think that your awful, whiny article (hosted on MSDN, LOL) is worth any discussion at all.

Lesson

[Jeffrey Baker]

I think the lesson here is not that this guy should have been more careful about programming, it's that no amount of careful programming can overcome a stupid design. It's stupid that there are magical filenames in the form of UUIDs that cause Explorer to load and run arbitrary DLLs. You can't get around this stupidity with some kind of speculative watchdog thread that works with what sound to me like some seriously questionable heuristics.

They should have simply got rid of the magic naming system in favor of something explicit, such as a Shell Extension Interface that a shell extension must fully implement.

Re:Lesson

[biscon]

"They should have simply got rid of the magic naming system in favor of something explicit, such as a Shell Extension Interface that a shell extension must fully implement." Seems to me like they had, how would you implement plugins otherwise?. The problem is that if explorer loads these plugins (which do adhere to an interface) and they do something stupid, explorer will hang, since it is the host process. This is bad since explorer.exe on windows is responsible for running the shell.
Therefore they choose to make a separate process (that vert something exe) try and load the plugin and run some tests. Questionable heuristics I agree, but giving those circumstances, I can't come up with any other way of doing it.
The magic names are used for creating instances of COM objects which as far as I know both KDE and Gnome also use in the form of DCOP and DBUS.

Re:Lesson

[I'm Don Giovanni]

You clearly have no clue how COM CLSIDs work, do you?
There is no "magic naming system". Each plugin implements the shell extention interface and registers its CLSID; when explorer needs to load the plugin for a particular CLSID, it looks it up in the registry, finds the corresponding dll, loads it, and accesses the shell extension's COM interface.

And to think that your post was modded "Insighful" rather than "Arrogantly Ignorant".

Re:Lesson

[Jeffrey Baker]

Thanks for your feedback ... The magic filenames are of the form {1768bcfe-9acf-4af5-b857-32eb9c640c4e} and if you name a file that way on the Desktop in Windows, Explorer looks up that UUID and loads the DLL, then QI's it into existence. The "magic" part here is that I can use _any_ DLL and Explorer will still try to QI it into a shell extension, which is obviously grossly unsafe, which is why they had to work around it.

Honesty

[florescent_beige]

This illustrates the kind of employee I like to have. One who can talk about his mistakes the same way he talks about anything else work-related.

Some years ago I myself made a rather expensive mistake which involved the design of an aircraft structure. The fellow I was working for at the time had one of those razor-blade intellects and I got called into his office for a chat. When he asked me what happened I had two choices, weasel or turkey. In engineering it's always possible to talk the complicated talk and hope to obfusticate your way out of a situation, but fortunately I said "I make a mistake." And you know what? That was exactly the answer he was looking for.

You see, the most important thing is not to be perfect, it's to be honest. That's what a boss, of which I am one now, wants.

If you have a boss that doesn't want that, better watch out for yourself.

Re:Honesty

[labnet]

Being a Boss as well, thats exactly what our culture looks for.
Honesty, but without emotional baggage.
A stuffup is a stuffup, learn and move on.

Reading /. for so many years now, you would think 90% of posters are uber humans that never make a mistake, and be dammed if you do. Not sure if I would want to work for most of the /. crowd.

This one bit a client of mine...

[ktakki]

On the day after Patch Tuesday, January 2006, I got a somewhat frantic call from a client. She's a lawyer, had a filing deadline, but could not save a document in MS Word. That's not all that this patch broke: you couldn't open My Computer or My Documents on the desktop (though you could navigate to them by typing the path in the Start -> Run box), and IE wouldn't let you type just "www.[website].com" in IE's address bar. You had to prepend the "http://".

I verified that "Save" and "Save As..." were not working in Word. Word would just hang and only Task Mangler could shut it down. I carry the Sysinternals utilities on CD and USB key, so I rebooted and ran FILEMON, REGMON, and PROCEXP to see what was happening when I tried to save a doc in Word. Sure enough, Word would spawn verclsid.exe as a child process and then hang.

I googled "verclsid" and "Explorer", got nothing on the web and about a dozen Usenet posts from people having the same problem. I played a hunch and renamed verclsid.exe to verclsid.exX. I do that when I'm manually hunting malware that leaves .exe and .dll files that are named just like Windows system files. Keeps my foot bullet-free.

Problem solved. When the patch for the patch came out, a working verclsid.exe was dropped in %system% and I deleted the .exX.

Oh, and the buggy third party shell extension came with a very common HP DeskJet printer. As for Google, the next day I googled "verclsid": there were hundreds of web results and Usenet hits. The day after, tens of thousands. This one bit a lot of people in the ass.

k.

education

[Anonymous Coward]

Reminds me of a famous story about Jack Welch, former GE CEO. One of the company's division managers made a mistake costing the company $10 million in one quarter. When the quarterly reports came out, he got a call from headquarters telling him to be in Welch's office in NY the next morning. Welch grilled the man for some time, asking him what he was thinking and how he could possibly lose so much money. When it seemed Welch had finished, the manager said he understood that Welch had to fire him now. To which Welch replied, "Why would I fire you when I just invested $10 million in your education?"

A bit more background info

[Marton]

This pretty much rendered Windows useless (explorer, file open / save dialogs and the IE7 addressbar were not working) if you had software installed for HP cameras, HP scanners, or any HP DeskJet printer that included a card reader.

Courtesy of JSI FAQ:

You experience one or more of the following strange behaviors:

- You are unable to open special folders, like My Documents or My Pictures.

- Some 3rd party applications hang when accessing My Documents.

- Office files won't open in Microsoft Office if they are stored in My Documents.

- Entering an address into Internet Explorer's address bar does nothing.

- The Send TO context menu has no effect.

- The plus (+) sign on a folder in Windows Explorer does nothing.

- Opening a file via an applications File / Open menu causes the application to hang.

This behavior is caused by a new VERCLSID.EXE binary, which validates shell extensions before Explorer.exe, the Windows Shell, can use them. VERCLSID.EXE is installed by the MS06-015 (908531) security update.

The following 3rd party applications cause VERCLSID.EXE to hang:

Hewlett-Packard's Share-to-Web Namespace Daemon ("%ProgramFiles%\hewlett-packard\hp share-to-web\Hpgs2wnd.exe), auto-started from the Registry Run key and the Startup menu, which ships with:

                HP PhotoSmart software
                Any HP DeskJet printer that includes a card reader
                HP Scanners
                Some HP CD-DVD RWs
                HP Cameras

Sunbelt Kerio Personal Firewall which has a feature that prompts when Explorer launches VERCLSID.EXE, but you can configure it not to prompt.

To workaround this behavior, add the HP shell extension to the VERCLSID.EXE white list:

1. Open a CMD.EXE window.

2. Type the following command and press Enter:

REG ADD "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Sh ell Extensions\Cached" /V "{A4DF5659-0801-4A60-9607-1C48695EFDA9} {000214E6-0000-0000-C000-000000000046} 0x401" /T REG_DWORD /F /D 1

3. Shutdown and restart your computer.

NOTE: If you find other COM controls or shell extensions that cause this behavior, you can add them to the white list.

Re:A bit more background info

[jZnat]

You see, it's this sort of advice that is preventing the year of Windows on the desktop. Once you say, "open a command line", you've failed as an operating system. ;p

Re:Backwards compatibility

[IamTheRealMike]

Its only useful in a closed-source world where you cannot modify programs to suit the new API's.

How much open source work have you actually done? I've done a lot, and this idea is one I see very often in people who haven't done any serious API development work before. The approach of attempting to patch every app when an API changes simply doesn't scale. There's a reason all the important open source APIs (gtk, glibc, alsa, X etc) have "gone stable" in the past 5 years, and it's simply a better approach.

Anyway, ignoring the obvious (!!) problems of scaling such an approach, you are confusing two unrelated things. Microsoft can simply/clean up APIs too - they have done it with DirectX and .NET, but that's irrelevant. The problem here is that there are lots of people in the world writing software who perhaps aren't well qualified, and even the ones that are well qualified make mistakes, even with the implementation of quite simple interfaces like IUnknown. I myself have messed up IUnknown before, in fact.

The root problem that caused the hang was attempting to cleanly handle buggy software. This is a common motif in software, hell, it practically motivated the move from the Windows 9x design to the NT fully protected architecture.

The result is that even Microsoft can't get reasonably trivial things right.

Multi-threading is never trivial.

Not to mention almost all Windows software code being highly complicated compared to equivalent code on other systems.

I worked on Wine for a long time, which implements or maps the Win32 API. The complexity of Linux, Windows and MacOS X are all much the same - they are of the same design era, even OS X which is based on lots of older code at its heart. While the more modern parts of the Linux APIs like GTK+ are better than the Win32 equivalents that's just an age thing: the Win32 API has evolved over a much longer period of time. That means it's uglier (the world has learned a lot about API design since the 80s), but it also means there are far more people out there who know it, better tools support, and critically, more apps that use it!

Re:Backwards compatibility

[Peaker]

There's a reason all the important open source APIs (gtk, glibc, alsa, X etc) have "gone stable" in the past 5 years, and it's simply a better approach.

But they only have to maintain source-level compatibility. Microsoft has to maintain binary-level compatibility.

Also, when specific things are extremely and seriously broken, compatibility can be dropped altogether, and some buggy programs broken. Microsoft cannot afford to break buggy programs, even if those are few and far between - nobody can fix them.

Multi-threading is never trivial.

Using a multi-threaded approach here, when SMP scalability is not an issue, suggests that either their API design is crap, and requires threading, or that their engineers are incompetent and use threads unnecessarily. Threads are never trivial - but what they were trying to do was quite trivial. Its their fault they involved threads in there.

The complexity of Linux, Windows and MacOS X are all much the same

Compare the complexity of APIs. fork/exec vs CreateProcess. open vs CreateFile. To use either of the Windows ones you have to call multiple APIs with multiple complicated structures documented upon pages and pages of explanations you must do more than skim through.

Windows may have similar complexity in some subsets of its APIs, but the Windows APIs I had the misfortune to use were insanely complicated unnecessarily.

Re:Backwards compatibility

[Bill Dog]

Using a multi-threaded approach here, when SMP scalability is not an issue, suggests that either their API design is crap, and requires threading, or that their engineers are incompetent and use threads unnecessarily. Threads are never trivial - but what they were trying to do was quite trivial. Its their fault they involved threads in there.

This is one of the stupidest comments I've read here in a long time. A secondary "watchdog" thread was employed to enforce a time-out on the helper program's sniffing of a given shell extension, so in case the main thread hung trial hosting a faulty shell extension, there would still be another thread of logic outside of the infinite loop that could run and tell Windows Explorer the result.

If you knew anything about what you're trying to talk about, you'd know that multi-threading is used for these kinds of situations, as well as in GUI programming. And not just "when SMP scalability is an issue". This has nothing to so with the Win32 API design, it just was tackling a very specific problem. It doesn't mean that the Win32 API "requires threading", or that MS's engineers are incompetent, and that they used an additional thread unnecessarily here. Threads can be trivial, and this is I would say actually the most trivial case of their use. It's to their credit that they involved threads here (and might actually have been the only way), and it's to your ignorance that you don't understand any of this and got everything wrong about it.

The flaw was in doing the WaitForSingleObject() in the DLL's detach process function without specifying a timeout value. Even if you have no reason to think that the thread won't be there to signal you eventually, sometimes the unthinkable occurs.

Re:Backwards compatibility

[Peaker]

Threading is used in GUI's so that redraws and responding to the user can still take place while it's processing the user's last command or commands. This is how "incompetent engineers" for the Win32 and Java platforms do it, at least. What pray tell are the "far simpler approaches"?

The far-simpler approach is to use asynchronous programming. Never use blocking API calls. All good API's always provide non-blocking interfaces.
If long computations are required, split them up into short computations and run the short computations asynchronously from the reactor (event loop).

And how do you write a program that hosts plug-in executable code, to check whether it will hang its host, without the "unnecessary complication" of another thread of execution, either in the program itself, or in another process, watching it?

Firstly, a process is not a thread. It is much safer and cannot cause another process's exit to hang or overwrite its memory/etc. Secondly, I would explicitly declare the interface the plugin must adhere to, and verify that it does, rather than just trying IUknown and watch it for "hanging" via a timeout heuristic.