Upcoming change in NACK behavior
Hello and welcome back from the holidays!
I will get around to describing how to use acknowledgements and deadlettering soon, but right now, those of you who are already using acknowledgements should know that there is a slight behavior change coming up in Windows Server 2008 and Vista SP1 for certain classes of negative acknowledgements (NACKs).
The classes involved are MQMSG_CLASS_NACK_ACCESS_DENIED (0x8004), MQMSG_CLASS_NACK_BAD_DST_Q (0x8000), MQMSG_CLASS_NACK_BAD_ENCRYPTION (0x8007), MQMSG_CLASS_NACK_BAD_SIGNATURE (0x8006), and MQMSG_CLASS_NACK_UNSUPPORTED_CRYPTO_PROVIDER (0x800B). The thing they have in common is that it is relatively easy for an attacker to craft a MSMQ message which will cause the destination machine to generate one of these NACKs. Depending on how the attacker sets the admin queue formatname in the message, these NACKs could pile up in an outgoing queue on the destination machine or they could spam some legitimate queue on that machine or elsewhere. It's not a very disastrous attack, but it is relatively easy, so in Windows Server 2008 and Vista SP1 these classes of NACKs are suppressed by default. The previous behavior, which was to generate these NACKs, can be restored by creating a DWORD registry value named PermitInsecureNacks under key HKLM\SOFTWARE\Microsoft\MSMQ\Parameters\Security and assigning the value 1 to it.
This behavior change can interact with the MSMQ authentication changes introduced in Windows Vista and described in an earlier posting, since the BAD_SIGNATURE NACK which characterizes some of the issues described there is now suppressed by default.
Comments
Anonymous
January 05, 2008
PingBack from http://geeklectures.info/2008/01/05/upcoming-change-in-nack-behavior/Anonymous
February 12, 2009
MSMQ is a protocol that can benefit from the odd tweak to the registry. Unfortunately it is not always