• Article

Security Bulletin

Microsoft Security Bulletin MS01-045 - Important

ISA Server H.323 Gatekeeper Service Contains Memory Leak

Published: August 16, 2001 | Updated: May 18, 2003

Version: 1.1

Originally posted: August 16, 2001
Updated: May 18, 2003

Summary

Who should read this bulletin:
System administrators running Microsoft® Internet Security and Acceleration (ISA) Server 2000.

Impact of vulnerability:
Denial of service; cross-site scripting

Recommendation:
System administrators should consider installing the patch.

Affected Software:

  • Microsoft ISA Server 2000

General Information

Technical details

Technical description:

This bulletin discusses three security vulnerabilities that are unrelated except in the sense that both affect ISA Server 2000:

  • A denial of service vulnerability involving the H.323 Gatekeeper Service, a service that supports the transmission of voice-over-IP traffic through the firewall. The service contains a memory leak that is triggered by a particular type of malformed H.323 data. Each time such data is received, the memory available on the server is depleted by a small amount; if an attacker repeatedly sent such data, the performance of the server could deteriorate to the point where it would effectively disrupt all communications across the firewall. A server administrator could restore normal service by cycling the H.323 service.
  • A denial of service vulnerability in the in the Winsock Proxy service. Like the vulnerability above, this one is caused by a memory leak, and could be used to degrade the performance of the server to point where is disrupted communcations.
  • A cross-site scripting vulnerability affecting the error page that ISA Server 2000 generates in response to a failed request for a web page. An attacker could exploit the vulnerability by tricking a user into submitting to ISA Server 2000 an URL that has the following characteristics: (a) it references a valid web site; (b)it requests a page within that site that can't be retrieved - that is, a non-existent page or one that generates an error; and (c) it contains script within the URL. The error page generated by ISA Server 2000 would contain the embedded script commands, which would execute when the page was displayed in the user's browser. The script would run in the security domain of the web site referenced in the URL, and would be able to access any cookies that site has written to the user's machine.

Mitigating factors:

H.323 Denial of service vulnerability:

  • The vulnerability could only be exploited if the H.323 Gatekeeper Service was installed. It is only installed by default if "Full Installation" is chosen; if "Typical Installation" is selected, it is not installed.
  • The vulnerability would not enable an attacker to gain any privileges on an affected server or add any traffic to an existing voice-over-IP session. It is strictly a denial of service vulnerability.

Winsock Proxy Service Denial of service vulnerability:

  • The vulnerability could only be exploited by an internal user; it could not be exploited by an Internet user.
  • The vulnerability would not enable an attacker to gain any privileges on an affected server or compromise any cached content on the server. It is strictly a denial of service vulnerability.

Cross-site scripting vulnerability:

  • In order to run script in the security domain of a trusted site, the attacker would need to know which sites, if any, a user trusted. Most users use the default security settings for all web sites, which would effectively deny an attacker any gain in exploiting the vulnerability for the purposes of running script.
  • An attacker who wished to read other sites' cookies on a user's machine would have no way to know which sites had placed cookies there. The attacker would need to exploit the vulnerability once for every web site whose cookies she wished to access.
  • Even if the attacker correctly guessed which sites had placed cookies on a user's machine, there should be no sensitive information in the cookies, if best practices have been followed.

Vulnerability identifier:

Tested Versions:

Microsoft tested ISA Server 2000 and Proxy Server 2.0 to assess whether they are affected by these vulnerabilities. Previous versions are no longer supported, and may or may not be affected by these vulnerabilities.

Frequently asked questions

What vulnerabilities are discussed in this bulletin?
This bulletin discusses three unrelated vulnerabilities affecting ISA Server 2000:

  • A vulnerability that could enable an attacker to disrupt service on an ISA server via an Internet Telephony service.
  • A vulnerability that could enable an attacker to disrupt service on an ISA server via the Winsock Proxy Service.
  • A vulnerability that could enable an attacker under very unusual conditions to take action or view cookies on a user's computer.

What's the scope of the first vulnerability?
The first vulnerability is a denial of service vulnerability. By repeatedly sending a particular type of malformed data, an attacker could degrade the performance of an affected ISA server, potentially to the point of disrupting communications across the server. Depending on where the server was located within the network, this could cause parts of the network to be isolated from each other, or for users inside the network to be unable to reach the Internet. The vulnerability only occurs if a particular service supporting IP telephony is enabled. This service is not installed by default in tyical installations.

What causes the vulnerability?
The vulnerability results because of a memory leak in the H.323 Gatekeeper Service in ISA Server.

What's the H.323 Gatekeeper Service?
H.323 is an international telephony standard that specifies how voice communications over media like the Internet should be handled. The H.323 Gatekeeper Service in ISA Server implements this standard, and allows voice-over-IP communications to pass through the firewall.

What's a memory leak?
A memory leak is an implementation error that depletes the available memory on a system. As a process on a computer runs, it may need more or less memory, depending on exactly what it is doing from one minute to the next. When the process needs more memory, it requests it from the operating system; when it no longer needs the additional memory, it should return it to the operating system so it can be allocated to other processes. If a process doesn't correctly return memory to the operating system, the memory remains assigned to the process even though the process is no longer using it, and the memory can't be re-allocated. This effectively makes the block of memory unavailable. In this case, the H.323 Gatekeeper Service has an implementation error that results in a memory leak when certain invalid data is sent to it.

What could an attacker do via this vulnerability?
An attacker could deliberately send a large number of the malformed H.323 data in order to deplete the server's available memory. As the attack continued and the pool of memory on the server was depleted, the server's performance would gradually slow, potentially to the point where it no longer provided any service at all.

Do you mean that a successful attack would prevent the H.323 service from performing useful work, or the entire ISA server?
The memory leak affects the pool of memory used by all software on the system, so a successful attack would affect the server as a whole.

What would be the effect of disrupting service on the system?
ISA Server can be configured to act as a firewall, a web proxy, or both. In either role, ISA serves as a communication conduit between parts of a network, or between the network and the Internet. If the H.323 Gatekeeper Service was attacked via this vulnerability, the effect would be to slow those communications or potentially block them altogether.

How could an affected server be put back into service?
The server administrator could restore normal service by stopping and starting ISA Server 2000.

Could this vulnerability be exploited from the Internet?
Yes. Both internal and external users can send data to the H.323 Gatekeeper Service.

Suppose the H.323 Gatekeeper Server was disabled. Could the vulnerability be exploited then?
No. The vulnerability only effects ISA servers that have the H.323 Gatekeeper Service enabled. The service is installed by default if "Full Installation" is chosen when installing ISA Server 2000; however, if "Typical Installation" is chosen, the H.323 Gatekeeper Service is not installed.

Does the vulnerability provide any way for an attacker to gain control over the server, or undermine the security of the firewall?
No. It could be used to gain any privileges on server. It could only be used to deny services to legitimate users.

Does the vulnerability provide any way for an attacker to eavesdrop on a voice-over-IP session, or to add bogus data to it?
No. It doesn't provide any way for an attacker to break into an existing H.323 session.

What does the patch do?
The patch causes the H.323 Gatekeeper Service to correctly allocate and deallocate memory, thereby removing the memory leak.

What's the scope of the second vulnerability?
This vulnerability is virtually identical to the first vulnerability above. Like that vulnerability, this one could be used to degrade the performance of a system running ISA Server 2000, potentially to the point where communications between the internal and external network would be disrupted. The seriousness of this vulnerability is mitigated somewhat by the fact that it could only be exploited from within a network.

What causes the vulnerability?
Like the vulnerability above, this one results because of a memory leak. In this case, the leak is in the Winsock Proxy Service of ISA Server 2000.

What would the effect of exploiting this vulnerability be ?
As in the case above, this vulnerability could enable an attacker to degrade the performance of an ISA Server, potentially to the point of disrupting communications across the proxy server.

Are there any differences between the two vulnerabilities?
Yes. Unlike the memory leak in the H.323 Gatekeeper Service, the one in the Winsock Proxy Service could only be exploited from within the network. That is, it would not be possible for an attacker on the Internet to exploit the vulnerability.

Is the Winsock Proxy Service installed by default?
Yes.

What does the patch do?
The patch causes the Winsock Proxy Service to correctly allocate and deallocate memory.

What's the scope of the third vulnerability?
This vulnerability could enable an attacker to perform either of two actions:

  • Cause web content to execute with the security settings appropriate to a trusted web site.
  • Read cookies set by a trusted web site.

In practice, however, exploiting this vulnerability would be a daunting challenge. The attacker would likely have no way to know which web sites, if any, a particular user trusted. Likewise, if best practices have been followed and a site's cookies do not contain any sensitive information, gaining the ability to read them wouldn't represent any gain for the attacker.

What causes the vulnerability?
The vulnerability results because an error message - specifically, the one ISA Server generates when it cannot retrieve a requested web page - is susceptible to cross-site scripting.

What's cross-site scripting?
Cross-site scripting is a type of security vulnerability that results when web content doesn't adequately filter its inputs. In most cases, cross-site scripting occurs when a web page accepts some kind of user input (e.g., a phrase to search for) and then creates a page using that input. If the page doesn't check for the presence of script within the user's input, the result is that the script, when processed as part of the web page, will run within the web site's domain. Such a condition isn't dangerous in the case in which the user provides the input - after all, the user could have performed the actions directly rather than performing them via the script. However, as discussed in the Cross-site Scripting FAQ, there are cases in which it's possible for a third party to "inject" inputs containing script into a user's web session. This does pose a hazard, because it could enable the third party's script to run in the user's browser using the security settings appropriate to the web page.

What can be done via cross-site scripting?
Cross-site scripting offers two possibilities for an attacker:

  • Running script in the security settings of another, presumably trusted, web site. For instance, suppose John trusted Web Site A and had relaxed his browser's security settings to let it take actions that were commensurate with that trust. Now suppose Jane identified a cross-site scripting vulnerability in Web Site A. If she could exploit it, the result would be that her script would appear to come from Web Site A, and would therefore run using the relaxed security settings John had set for it.
  • Reading and writing cookies. Because the script would run as though it came from Web Site A, any cookies that Web Site A had set on John's computer could be accessed and modified by Jane's script.

What does this have to do with ISA Server?
When ISA Server is asked to retrieve a web page but cannot - because the page doesn't exist, because the server isn't available, etc - it generates error information to be displayed in the user's browser. This error information takes the form of a web page, and includes the URL that was requested. However, ISA doesn't check the URL for the presence of script commands when generating the page, with the result that it's vulnerable to cross-site scripting.

What would this allow an attacker to do?
Like all cross-site scripting vulnerabilities, this would could potentially enable an attacker to run code in another web site's security domain, or access the site's cookies.

How might an attacker exploit the vulnerability?
The attacker could try to exploit the vulnerability in either of two ways:

  • By including a link on her web site to an unavailable page on a web site that she believed another user, operating behind an ISA Server, trusted. If she could persuade the user to visit her web site, she could cause the bogus link to fire, thereby exploiting the vulnerability.
  • By including a link within an HTML mail and mailing it to her target. The bogus link would fire when the recipient opened the mail.

How dangerous is this vulnerability?
Microsoft recommends taking all security vulnerabilities seriously. Still, it can be seen that exploiting this vulnerability would be difficult, whether exploited for the purpose of running script with a trusted site's security settings, or to obtain another site's cookies.

  • The problem for an attacker who wanted to run code with another site's settings is that it would be difficult or impossible to know which sites another user trusts. In fact, most users don't modify their security settings from the default, in which case the attacker's code would run with exactly the same security restrictions no matter what site it appeared to come from.
  • The difficult with regard to cookies is that if a web site correctly handles cookies, there wouldn't be any sensitive information in them to compromise.

I heard that some web sites keep information in cookies that couldn't be used to log on as me, but which would let someone "hijack" a session once I started it. What if the attacker used this vulnerability to read such a cookie?
It's true that some web sites keep session information in cookies, to identify the user while a session is underway. If an attacker managed to gain access to such a cookie, it could be possible to "hijack" a session, by which we mean that the attacker might be able to insert commands into the session. However, it's important to keep this scenario in perspective.

  • In most cases, the attacker would have no way to know whether a particular user subscribed to a service that used such cookies.
  • Even if the attacker knew that a user subscribed to such a service, there would in general be no way for the attacker to solve the timing problem - namely, how to get the user to fall victim to the attack after starting a session with the specific service the attacker wanted to hijack.
  • Even if the attacker gained the session information, actually hijacking a session could be quite difficult. It would likely require the attacker to send packets "in the blind", with no way to tell whether the attack had succeeded.

What does the patch do?
The patch causes ISA Server to no longer support URL tokens within ISA Web Proxy error pages.

Patch availability

Download locations for this patch

Additional information about this patch

Installation platforms:

This patch can be installed on systems running ISA Server 2000 Gold.

Inclusion in future service packs:

The fix for this issue will be included in ISA Server 2000 Service Pack 1.

Reboot needed: Yes

Superseded patches:

This patch supersedes the one provided via Microsoft Security Bulletin MS01-021. Verifying patch installation: - To verify that the patch has been installed on the machine, confirm that the following registry key has been created on the machine:
HKEY_LOCAL_MACHINE \Software\Microsoft\FPC\Hotfixes\ISA3.0\68.

  • To verify the individual files, use the date/time and version information provided in Knowledge Base article Q289503.

Caveats:

None

Localization:

The patch can be installed on all systems running ISA Server 2000, regardless of language version.

Obtaining other security patches:

Patches for other security issues are available from the following locations:

  • Security patches are available from the Microsoft Download Center, and can be most easily found by doing a keyword search for "security_patch".
  • Patches for consumer platforms are available from the WindowsUpdate web site.

Other information:

Acknowledgments

Microsoft thanks the following people for working with us to protect customers:

  • Peter Grundl for reporting the memory leaks in the H.323 Gatekeeper Service and the Winsock Proxy Service.
  • Dr. Hiromitsu Takagi for reporting the cross-site scripting vulnerability.

Support:

  • Microsoft Knowledge Base articles Q289503 and Q295389 discuss this issue and will be available approximately 24 hours after the release of this bulletin. Knowledge Base articles can be found on the Microsoft Online Support web site.
  • Technical support is available from Microsoft Product Support Services. There is no charge for support calls associated with security patches.

Security Resources: The Microsoft TechNet Security Web Site provides additional information about security in Microsoft products.

Disclaimer:

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.

Revisions:

  • V1.0 August 16, 2001: Bulletin Created.
  • V1.1 (May 18, 2003): Updated download links to Windows Update and information on Cross-Site Scritping.

Built at 2014-04-18T13:49:36Z-07:00