Advance info for "Patch Tuesday"

Microsoft has released advanced warning about the bulletins it will be releasing next Tuesday. http://www.microsoft.com/technet/security/bulletin/advance.mspx


* 5 Security Bulletins for Windows, maximum level Critical

* 1 Security Bulletin for Office, level Critical

* 1 Security Bulletin for MSN Messenger, level Critical

* 1 Security Bulletin for Exchange, level Critical

Yellow

The InfoCon is currently set at yellow in response to the DNS cache poisoning issues that we have been reporting on for the last several days. We originally went to yellow because we were uncertain of the mechanisms that allowed seemingly "secure" systems to be vulnerable to this issue. Now that we have a better handle on the mechanisms, WE WANT TO GET THE ATTENTION OF ISPs AND ANY OTHERS WHO RUN DNS SERVERS THAT MAY ACT AS FORWARDS FOR DOWNSTREAM Microsoft DNS SYSTEMS. If you are running BIND, please consider updating to Version 9. Read on for more information...

DNS cache poisoning update

We have received more technical details on the software configurations
that are vulnerable. Thanks to Microsoft for clarifying details on
Windows DNS and thanks to numerous others for reporting. We try to get
all the technical details right before publishing information on attacks
like this, but if we waited until we were 100% sure all the time, we
would never be able to notify the community when the attacks are
actually happening.


On Windows 2000 SP3 and above, the DNS server DOES protect against DNS
cache pollution by default. The registry key to protect against the
poisoning is not necessary: the value is TRUE if the registry key does
not exist. Microsoft has now corrected the KB article that we published
earlier with this information.

    http://support.microsoft.com/default.aspx?scid=kb;en-us;241352 

    http://support.microsoft.com/kb/316786 

On Windows 2000, you should manage the DNS cache protection security
setting through the DNS Management Console. On Windows 2000 below SP3,
the "Secure cache against pollution" is not the default so you should
enable it using the DNS Management Console. On Windows 2000 SP3 and
above (and Windows 2003), the secure setting is the default (even if the
registry key does not exist).


Our recommendation is to only set the registry key
(HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\Parameters) on
Windows NT4. Otherwise, use the DNS Management Console. If you are on
Windows 2000 and you created the key already, you are safe to leave it
in place as long as the value is "1".


There seems to be other possible scenarios where cache poisoning can
occur. When forwarding to another server, Windows DNS servers expects
the upstream DNS server to scrub out cache poisoning attacks. The
Windows DNS server accepts all data that it receives, regardless of the
setting for protecting against cache poisoning. So vulnerability of the
attack depends upon whether the upstream DNS server is filtering out the
attack.


We are currently trying to determine the behavior of DJBDNS, and BIND
versions 4, 8, and 9 when acting as a forwarder. We are asking for
assistance from the community to determine their behavior so write us
if you have details. It appears that BIND4 and BIND8 do not scrub the
data, whereas BIND9 does. See the following scenarios:


Windows DNS --> forwarding to BIND4 or BIND8. Windows DNS server
assumes that BIND scrubs out the poisoning attempt. BIND4 and BIND8 do
NOT appear to scrub the attack. Windows DNS trusts the data and the
Windows DNS cache will become poisoned.


Windows DNS --> forwarding to BIND9. This configuration seems to be
secure because BIND9 scrubs the poisoning attempt.


Windows DNS (slave) --> forwarding to Windows DNS (master). In this
scenario, your vulnerability is based on the vulnerability of the
master. If the master is vulnerable, then it will be poisoned and
forward the attack to the slave server, which will also be poisoned.
However, if the master is secure then both servers should be safe.


The following recommendations are based on the current assumption that
BIND4 and BIND8 forwarders will not filter the cache poisoning attack to
its downstream clients. If we find out that this is not the case, then
the recommendations may not be valid. If you have Windows DNS servers
forwarding to BIND4 or BIND8, you should start investigating an upgrade
of those BIND servers to BIND9. If upgrading to BIND9 would not be a
possibility, a secondary recommendation would be to turn off the
forwarding on Windows DNS and allow the server to contact the Internet
directly so that it can apply the proper protection against cache
poisoning. If you run an ISP and have clients that are using your DNS
servers as forwarders, you may want to consider upgrading your resolvers
to BIND9 in order to protect your clients.


Alternatively, if you have Windows DNS servers that are functioning as
forwarders then you should verify that those machines are protected,
which should protect the rest of the DNS servers behind it.