What's the scope of the vulnerability?
This is a cross-site scripting (XSS) vulnerability that could allow an attacker to craft a request to an affected server that would cause a Web page containing script to be sent to another user. The script would execute within the user's browser as though it had come from the third-party site. This would let it run using the security settings appropriate to the third-party Web site, as well as allowing the attacker to access any data belonging to the site. The vulnerability could only be exploited if the user opened an HTML-based e-mail or clicked a specially-crafted link.
What's cross-site scripting?
Cross-site scripting (XSS) is a security vulnerability that potentially enables a malicious user to "inject" code into a user's session with a Web site. Unlike most security vulnerabilities, XSS doesn't apply to any single vendor's products - instead, it can affect any software that runs on a Web server and that doesn't follow defensive programming practices.
How does XSS work?
At a high level of detail, here's how XSS works. Suppose that Web site A offers a search feature that lets a user type a word or phrase to search for. If the user typed "banana" in as the search phrase, the site would search for the phrase and then generate a Web page saying "I'm sorry, but I can't find the word 'banana'.". It would send the Web page to the user's browser, which would then parse the page and display it. Now suppose that, instead of typing "banana" as the search phrase, the user typed something like "banana ‹SCRIPT› ‹Alert('Hello');› ‹/SCRIPT›". If the search feature were written to blindly use whatever search phrase it's provided, it would search for the entire string and create a Web page saying "I'm sorry, but I can't find the word "banana ‹SCRIPT› ‹Alert('Hello');› ‹/SCRIPT›"". However, all of the text beginning with "‹SCRIPT›" and ending with "‹/SCRIPT›" is actually program code, so when the page was processed, a dialog box that says "Hello" would appear by the user's browser.
So far, this example has only shown how a user could "relay" code off a Web server and make it run on his own computer. This is not a security vulnerability. However, it's possible for a malicious Web site operator to invoke this vulnerability to run on the computer of a user who visits his site. If Web site B were operated by a malicious user who was able to entice the user into visiting it and clicking a hyperlink, Web site B could go to Web site A, fill in the search page with malicious script, and submit it on behalf of the user. The resulting page would return to the user (because the user, having clicked on the hyperlink, was ultimately the requester), and process on the user's computer.
What could the script do on the user's machine? In the security context of Web site A?
The script from Web site B (the attacker's site) would run on the user's computer as though it had come from Web site A. In practical terms, this would mean that it would run using the security settings on the user's machine that were appropriate to Web site A.
The script from Web site B would be able to access cookies and any other data on the user's system that belonged to Web site A.
What is ISA Server?
ISA Server provides both an enterprise firewall and a high-performance Web cache. The firewall protects the network by regulating which resources can be accessed through the firewall, and under what conditions. The Web cache helps improve network performance by storing local copies of frequently-requested Web content. ISA Server can be installed in three modes: firewall mode, cache mode, or integrated mode.
Could an attacker use the vulnerability to take control of an ISA Server computer?
No. This is a cross-site scripting attack only. There is no capability to usurp any administrative privileges on the ISA Server.
Could an attacker use the vulnerability to breach the security of the firewall?
No. There is no capability to use this vulnerability to lower the security the firewall provides to the network. Firewall mode allows an administrator to secure network communication by configuring rules that control communication between the corporate network and the Internet. Cache mode improves network performance by storing frequently accessed Web pages on the server itself. In integrated mode, all cache and firewall features are available.
What causes the vulnerability?
The vulnerability results because some of the error pages returned by ISA Server display the requested URL in HTML text without proper encoding.
What's wrong with ISA Server error pages?
The homepage() function in many of the ISA error pages does not correctly encode the URL for displaying in HTML text. As a result, it is possible to embed a link to script on a separate Web site and cause this to be returned to the Web browser.
What would this vulnerability enable an attacker to do?
The vulnerability would allow an attacker who operated a Web site and was able to lure another user into clicking a link on it to carry out a cross-site scripting attack via another Web site that was running through ISA Server. This would enable the attacker to run script in the user's browser using the security settings of the other Web site, and to access cookies and other data belonging to it.
How could an attacker exploit this vulnerability?
To exploit this flaw, an attacker would have to first be aware of a specific ISA server and its access policies, or host an ISA server of their own and create specific access policies designed to exploit this vulnerability. The attacker could then craft a request to trigger a page refusal. Once the attack was crafted, the attacker would have to host a Web site containing the link or send the link to the user in the form of an HTML e-mail. After the user previewed or opened the e-mail, the malicious site could be visited automatically without further user interaction. In the Web-based attack scenario, an attacker would have no way to force a user to visit the Web site.
You said that the point of the attack would be for the attacker to get script running in the user's browser using the security settings of my Web site. What specific capabilities would the attacker gain by doing this?
It would vary from site to site, based on what Security zone the attacker's site and yours were placed in.
If they were both in the same zone (and, by default, all Web sites reside in the Internet zone unless the user moves them), they would both be subject to exactly the same security restrictions, and the attacker would gain different abilities through the vulnerability. For instance, an attacker could affect the relationship between a user and their Web-based e-mail.
If the user had put the attacker's site into a more restricted zone than yours, the attacker would gain the ability for his script to do anything on the user's computer that script from your site could do.
If the user had put your site into a more restricted zone than yours, the attacker would actually lose capabilities through the attack.
It's important to note, however, that regardless of the security settings, the attacker's script would always be able to access cookies and any other data on the user's system belonging to the third-party site. This is because, as far as the browser can tell, the attacker is the third-party site.
How does the patch eliminate the vulnerability?
The patch eliminates the vulnerability by removing the homepage() functionality as well as the JavaScript command for refreshing the page and for navigating back.
