MS07-065 fixed a vulnerability in the Message Queueing service. On Windows 2000, a remote anonymous attacker could use this vulnerability to run code as local system on unpatched machines. Windows XP added defense-in-depth hardening to disallow remote access for this service that does not need to be exposed remotely. So on Windows XP, the attacker must be logged on locally on the box.
You’ll see in the mitigations section of the bulletin that the MSMQ service is not started by default. Most installations of Windows do not require message queueing so the default install having it off by default reduces attack surface.
There is actually another mitigating factor present here that we didn’t include in the bulletin because we could not authoritatively say that it was true in every case. The vulnerable code path only executes if your machine has a primary DNS suffix. Most of the time, only domain-joined machines have a primary DNS suffix. So it would have been great to say in the bulletin: “Machines not joined to a domain are safe” but that is not 100% accurate so we did not include that. Technically, an administrator could manually set a primary DNS suffix on a non-domain-joined machine.
You can check to see if your machine has a primary DNS suffix by running “ipconfig /all” and looking for the line that says “Primary Dns Suffix”. If it is blank, your computer configuration is not vulnerable to this issue. If you do have a primary DNS suffix set, we would not recommend removing it blindly because that could affect many applications and the ability for your machine to access network resources.
We periodically identify workarounds or mitigations like this that we can’t use for official guidance because they’re either too nuanced or have some exception cases. When we discover something potentially useful but are uncomfortable listing it in the bulletin, we’ll do our best to describe it here in this blog.