Microsoft Security Bulletin (MS99-053)
What's this bulletin about?
This bulletin announces the availability of a patch that eliminates a vulnerability in the SSL ISAPI filter that is provided as part of Microsoft® Internet Information Server 4.0. This filter is used by other Microsoft products, including Site Server and Site Server Commerce Edition. Under very rare circumstance, the vulnerability could cause a server to allow a single buffer of plaintext information to leak back to its owner. Microsoft takes security seriously, and is providing the bulletin to inform customers of the vulnerability and what they can do about it.
What's the scope of the vulnerability?
This vulnerability could cause limited amounts of plaintext data to be transmitted during an SSL session under very rare circumstances. It could not happen unless the SSL session was running on a machine using the IIS SSL ISAPI filter to perform multi-threaded SSL sessions. Even then, it could only occur under extremely high traffic volumes.
In the event that the vulnerability did occur, the data would be sent back to the owner, and would cause the SSL session to collapse immediately. The session could be restarted without incident, and the odds of the situation recurring would be the same as of it happening in the first place. Even if a malicious user were eavesdropping on a session, he or she could not cause the vulnerability to occur; the best they could hope for would be to happen to be present when such an error occurred.
It's important to note that the vulnerability only affects applications that use the IIS SSL ISAPI filter. It does not affect applications that use any other SSPI provider, including the Windows NT Secure Channel.
What is the vulnerability?
The vulnerability is due to a race condition in the IIS ISAPI filter. When called by a multithreaded application under certain conditions, the threads can interfere with each other and a transmitting thread could send decrypted, received data.
What is the SSL ISAPI filter?
ISAPI filters are DLLs that can be written to extend or modify the server's behavior. Among the ISAPI filters that are available is one that implements Secure Sockets Layer session encryption.
How could the race condition occur?
The SSL ISAPI filter in IIS supports multi-threaded use as a way of improving server performance. If a user's SSL session were multi-threaded, the two threads could potentially interfere with each other. Specifically, one thread could have received data and decrypted it just as another thread was preparing to encrypt data and send it. If the timing were exactly right, the sending thread could interfere with the receiving thread in such a way as to cause the decrypted data to be sent.
How serious is this problem?
Any time plaintext data is leaked from an encrypted session, it's serious. However, the circumstances in which this error occurs combine to ensure that the leak would be temporary and plaintext data would not be sent to other users. Just the same, if a malicious user were eavesdropping on a session in which data were leaked, he or she would be able to see it.
How likely is this problem to occur?
It's very rare. It cannot happen unless the application that calls the SSL ISAPI filter is multi-threaded, and even then, only threads belonging to the same user session can interfere with each other.
A number of other factors determine how likely the problem is to occur. Extremely high traffic volumes are needed in order for the threads to interfere. Longer buffers, and longer encryption keys would increase the likelihood of the problem occurring.
The rarity of this problem can be judged by the fact that the effect of sending the plaintext data would be to cause the SSL session to immediately collapse immediately. If this problem occurred often, sites using affected products would have registered a higher-than-normal rate of SSL session collapse. However, we have no data to suggest that that this is the case.
Could I receive someone else's plaintext data through this vulnerability?
No. Only two threads belonging to the same session could interfere with each other in the particular way needed for this vulnerability to occur. As a result, the data could only be sent back to its owner. However, if someone were eavesdropping on the user's session, they could see the plaintext data.
If the problem did occur, would it be a persistent condition?
No. The plaintext data would fail its integrity check, and would cause the SSL session to immediately collapse. The session could be restarted, but the problem would be no more likely to re-occur than it was to occur in the first place.
Could a malicious user cause this vulnerability to occur?
No. The factors that cause the plaintext to leak are entirely out of an attacker's control. However, if a malicious user were "sniffing the wire" when a plaintext buffer happened to leak, they could see it.
Does this affect Windows NT Secure Channel communications?
No. Secure Channel, or Schannel, is a Windows NT service that enables secure communications among Windows NT servers. Schannel is completely separate from the SSL ISAPI filter, and is not affected by this vulnerability.
Where can I get the patch?
The download location for the tool is provided in the "Patch Availability" section of the security bulletin.
How can I tell if I installed the patch correctly?
Use the following table to verify that you've installed the patch correctly.
| If you are running on this platform... | You've installed the patch correctly if SSPIFILT.DLL has these properties... |
Intel | Date: October 26, 1999 |
Alpha | Date: October 26, 1999 |
Did Microsoft handle this vulnerability differently from previous ones?
Yes. Because SSL is used in e-commerce systems, Microsoft alerted high-volume e-commerce providers who would be most likely to be affected by this vulnerability, and provided an advance copy of the patch. Normally, when Microsoft develops a security patch, we release to all customers at once. However, in this case, the vulnerability had a disparate impact on one group of customers. We therefore worked privately with them to ensure that they had the patch in place before we did a general release.
Will this patch be incorporated into the version of IIS that ships with Windows 2000?
Yes. IIS 5.0, the version of the IIS that will ship with Windows 2000, already has been corrected.
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 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.
