Microsoft Security Bulletin (MS99-046) Frequently Asked Questions
What's this bulletin about?
This bulletin announces the availability of a patch that improves the security of Microsoft® Windows NT. The patch makes the initial sequence numbers (ISNs) used in TCP/IP sessions less predictable. Microsoft takes security seriously, and is providing the bulletin to inform customers of the availability of the patch and the issues associated with ISN predictability.
Why has the bulletin been re-released?
The patch was withdrawn in November because a regression error was discovered in it. We have re-released to inform customers that a corrected version is now available.
What was the regression error?
The regression error prevented non-administrative users from connecting to the server under certain conditions. Microsoft Knowledge Base article 245678 contains additional information on the error.
Were all versions of the patch affected by the regression error?
Yes.
If I installed the original patch, what do I need to do to install the new one?
Just install it as normal. You do not need to "back out" the original patch or take any other action.
Is there a security vulnerability here?
Not precisely. The issue here is the predictability of the ISNs used by Windows NT TCP/IP sessions. In order to prevent certain attacks, ISNs should be as random as possible. The more random they are, the more difficult the attacks are made. The patch makes the TCP/IP ISNs used by Windows NT significantly more random.
If there's not a vulnerability here, why are you releasing a patch?
The algorithm that generates ISNs in Windows NT 4.0 was not as strong as it could be. Although not perfectly predictable, certain sequence numbers were used more frequently than others. As discussed below, this could make certain attacks more feasible than they otherwise would be.
How predictable are the Windows NT ISNs? How much does the patch improve the randomness?
The Windows NT 4.0 ISN algorithm is no more predictable than those of many other vendors. The patch implements the same algorithm as will be included in Windows 2000. This algorithm produces ISNs whose randomness meets or exceeds that of any other vendor.
What are TCP ISNs, and how are they used?
TCP sequence numbers are used to provide flow control and data integrity for TCP sessions. Every octet of bits, or byte, in a TCP session has a unique sequence number. Every TCP segment provides, as part of the segment header, the sequence number of the initial byte that it contains. However, the sequence numbers don't start at zero for each session. Instead, the participants specify initial sequence numbers as part of the handshake process-a different ISN for each direction-and begin numbering the bytes from there.
For example, suppose that Host A and Host B have established a session, and the ISN for the Host A-Host B direction was 1111 while that for the Host B-Host A direction was 2222. Now suppose that Host A had already sent 1000 bytes in the session. The next TCP segment Host A sent would carry a sequence number of 2112. Likewise, if Host B had already sent 2000 bytes, the next segment it sent would carry a sequence number of 4223. The important point for our discussion, though, is that the initial sequence numbers used in the session should be as random as possible.
Why should TCP ISNs be random?
If an attacker can predict how a host selects ISNs, it's possible to conduct two types of attacks, known as IP address spoofing and session hijacking. The more random the ISNs are, the more difficult it is to carry out these attacks.
What is IP Address Spoofing?
In IP address spoofing, a malicious user conducts a one-sided session with his or her target. Suppose that John wants to pose as Jane and send a phony email via an SMTP mail server named \\Mail. It would be fairly easy for John to construct a series of packets that represent a valid mail session between Jane and \\Mail-that is, a series of packets which, if sent by Jane to \\Mail would cause it to send the desired email. All of the response packets from \\Mail would go to Jane, so John would be operating in the blind. However, SMTP sessions are fairly easily scripted, and this wouldn't be a fatal problem.
The chief problem for John is that he would need to provide valid sequence numbers on the packets, but \\Mail provides the initial sequence number as part of the session setup-which would be sent to Jane, not John. John must therefore guess at the initial sequence number. One way to do this is to start a session with \\Mail and immediately cancel it, simply as a way of determining the current ISN \\Mail is using. If \\Mail is using a predictable ISN generation algorithm, John could guess what ISN would be assigned to the next session it opens, and could use this as the ISN for his spoofed session.
How easy it is for John to determine what ISN will be used depends on the quality of the ISN algorithm. If it were trivially predictable, John might know with great certainty what the ISN would be. If it were of moderate quality, John might be able to narrow the ISN down to a narrow range, in which case he could simply send multiple copies of the scripted packets, each assuming a different ISN. At some point, the quality of the ISN algorithm would reach a point where it isn't feasible for John to create enough scripted sessions.
Note that there are additional problems associated with IP address spoofing than we have outlined above. For instance, John would need to take steps to keep Jane from responding to all of the packets that she would receive from \\Mail. However, none of these additional issues are associated with ISNs.
How does session hijacking work?
Session hijacking is even more difficult than IP address spoofing. In session hijacking, John would seek to insert himself into a session that Jane already had set up with \\Mail. John would wait until Jane established a session, then knock her off the air by some means and pick up the session as though he was her. As before, John would send a scripted set of packets to \\Mail but would not be able to see the responses. To do this, he would need to know the sequence number in use when he hijacked the session, which could be calculated knowing the ISN and the number of packets that have been exchanged.
Successful session hijacking is extremely difficult and only possible when a number of factors are under the attacker's control. Knowledge of the ISN would be the least of John's challenges. For instance, he would need a way to knock Jane off the air at will. He also would need a way to know the exact status of Jane's session at the moment he mounted his attack. Both of these require that John have far more knowledge about and control over the session than normally would be possible.
How great a threat are IP address spoofing and session hijacking?
Although both attacks are possible and we recommend that you take them seriously, there is a fair amount of hype surrounding them. Here are some facts to put the risk into perspective:
| • | IP address spoofing attacks can only be successful if IP addresses are used for authentication. However, Windows NT in general does not use IP addresses for authentication. Every session requires a challenge-response authentication. |
| • | Neither IP address spoofing nor session hijacking are possible if per-packet integrity checking is performed. |
| • | Neither IP address spoofing nor session hijacking are possible if session encryption such as SSL or PPTP are used, because the malicious user will not have a way to participate in the key exchange. |
How random are the TCP ISNs in Windows 2000?
They are very random. In fact, this patch is a backport of the Windows 2000 algorithm.
Where can I get the patch?
The download location for the patch is provided in the "Patch Availability" section of the security bulletin.
Is this patch included in Windows NT 4.0 Service Pack 6?
No. Service Pack 6 was too far advanced in its development to allow this patch to be incorporated into it. However, it will be incorporated into Service Pack 7.
If I install Service Pack 6, will I need to re-apply this patch?
Yes.
What machines should I apply the patch to?
Microsoft recommends that customers assess the risk posed to their systems and apply the patch to any that warrant it. The patch will be of greatest benefit to servers that have direct connections to the Internet, especially e-commerce servers, web servers and so forth, but also should be considered for internal servers that hold high-value data, like HR servers.
How can I tell if I installed the patch correctly?
The Knowledge Base provides a manifest of the files in the patch package.The easiest way to verify that you've installed the patch correctly is to verify that these files are present on your computer, and have the same sizes and creation dates as shown in the KB article.
What is Microsoft doing about this issue?
| • | Microsoft has developed a patch that eliminates the vulnerability. |
| • | Microsoft has provided a security bulletin and this FAQ to provide customers with a detailed understanding of the vulnerability and the patch. |
| • | Microsoft has sent copies of the security bulletin to all subscribers to the Microsoft Product Security Notification Service, a free e-mail service that customers can use to stay up to date with Microsoft security bulletins. |
| • | Microsoft has issued a Knowledge Base article explaining the vulnerability and patch in more detail. |
Where can I learn more about best practices for security?
The Microsoft Security Advisor web site is the best to place to get information about Microsoft security.
How do I get technical support on this issue?
Microsoft Technical Support can provide assistance with this or any other product support issue.
THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.
