[NT] Unchecked Buffer in Gopher Protocol Handler Can Run Code of Attacker's Choice

From: support@securiteam.com
Date: 06/13/02 

From: support@securiteam.com
To: list@securiteam.com
Date: Thu, 13 Jun 2002 00:00:37 +0200 (CEST)

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -

  Unchecked Buffer in Gopher Protocol Handler Can Run Code of Attacker's
Choice
------------------------------------------------------------------------

SUMMARY

This is a work-around bulletin that details steps customers can take to
protect themselves against a publicly disclosed vulnerability until
patches are available.

The Gopher protocol is a legacy protocol that provides for the transfer of
text-based information across the Internet. Information on Gopher servers
is hierarchically presented using a menu system, and multiple Gopher
servers can be linked together to form a collective "Gopherspace".

There is an unchecked buffer in a piece of code which handles the response
from Gopher servers. This code is used independently in IE, ISA, and Proxy
Server. A security vulnerability results because it is possible for an
attacker to attempt to exploit this flaw by mounting a buffer overrun
attack through a specially crafted server response. The attacker could
seek to exploit the vulnerability by crafting a web page that contacted a
server under the attacker's control. The attacker could then either post
this page on a web site or send it as an HTML email. When the page was
displayed and the server's response received and processed, the attack
would be carried out.

A successful attack requires that the attacker be able to send information
to the intended target using the Gopher protocol. Anything which inhibited
Gopher connectivity could protect against attempts to exploit this
vulnerability. In the case of IE, the code would be run in the user's
context. As a result, any limitations on the user would apply to the
attacker's code as well.

DETAILS

Affected Software:
 * Microsoft Internet Explorer
 * Microsoft Proxy Server 2.0
 * Microsoft ISA Server 2000

Mitigating factors:
 * A successful attack requires that the attacker's server be able to
deliver information to the target using the Gopher protocol. Customers who
block Gopher at the perimeter would be protected against attempts to
exploit this vulnerability across the Internet.
 * In the case of IE, code would run in the security context of the user.
As a result, any limitations on the user's ability would also restrict the
actions an attacker's code could take.
 * A successful attack against ISA and Proxy servers would require that
the malicious response be received by the web proxy service. In practical
terms, this means that a proxy client would have to submit the initial
request through the proxy server.

Patch availability:
Download locations for this patch
 * Patches are under development and will be posted as soon as they are
completed.

Why is Microsoft releasing a work-around bulletin rather than a patch for
this issue?
Microsoft is currently working on patches to address this vulnerability.
However, the information required to exploit this vulnerability has been
released before the patches have been completed. To allow customers to
take action to protect themselves while the patches are built, Microsoft
is releasing work-around information. Microsoft will update this bulletin
to announce the availability of patches as soon as they are available.

What is the scope of this vulnerability?
This is a buffer overrun vulnerability. A successful exploit of this
vulnerability could enable an attacker to run code on the local system. An
attacker could seek to exploit this vulnerability by creating a specially
formed web page that would contact a server under the attacker's control.
The web page could either be posted on a web site under the attacker's
control or sent as an HTML email. When the attacker's server returned
information to the target, the vulnerability could be exploited and the
attacker's code would run in the context of the program that submitted the
request to the attacker's server.

In the case of ISA and Proxy Server, the attacker's code would run in the
LocalSystem context. This could give the attacker complete control over
the server and allow them to take any action on the server including but
not limited to formatting the hard drive, adding administrators to the
system, and loading network services.

In the case of IE, the attacker's code would run in the user's context.
This means that it could take any action that user could, including
adding, changing or deleting files or changing security settings.

Successfully exploiting the vulnerability requires that the intended
target be able to receive information from an attacker's server using the
Gopher protocol. Anything that prevents this access, such as blocking the
Gopher protocol or blocking access to the attacker's server, would have
the effect of preventing against attempts to exploit this vulnerability.
In addition, in the case of IE, the code would run in the security context
of the user. As a result, any limitations on the user's account would also
apply to the attacker's code. For example, if a user were prevented by
security policies from deleting files or changes security settings, the
attacker's code would also be prevented from those actions.

What causes the vulnerability?
The vulnerability results because of an unchecked buffer in code which
handles information returned from a server using the Gopher protocol. By
configuring a Gopher server to return information in a particular manner
in response to requests, and attacker could attempt to overflow the buffer
and load code on the system.

Why does this vulnerability affect ISA and Proxy Servers in addition to
IE?
The particular piece of code which has the unchecked buffer is used
independently in ISA and Proxy Servers, in addition to being used in IE.

What is Gopher?
Gopher is network protocol or language that supports the transfer of
information across the Internet. In many ways, it is similar to HTTP, the
protocol that is the language of the World Wide Web. Unlike HTTP, however,
Gopher is completely text based. The Gopher protocol is discussed in RFC
1436.

Gopher works to organize the information on a site into a hierarchical
menu. In addition, multiple Gopher sites can be linked together by menus
creating what is referred to as "Gopherspace".

Most of the functions and capabilities of Gopher have been superceded by
HTTP. Gopher is mainly used now to provide legacy support for information
that has not been migrated to web sites.

The protocol is called Gopher after the mascot of the University of
Minnesota where it was first developed.

What's wrong with how Gopher is handled?
There is an unchecked buffer in the code which handles information
returned from a Gopher server.

What could this vulnerability enable an attacker to do?
This vulnerability could enable an attacker to levy a buffer overrun
attack and attempt to run code in the same process space as the running
program. As a consequence, an attacker's code could run with the same
privileges as the running program.

In the case of ISA and Proxy Server, this could enable an attacker to run
code as the operating system. This would give the attacker complete
control over the server.

In the case of IE, this could enable an attacker to run code as the
currently logged on user. The attacker would be able to do anything that
the user could. The attacker would also be limited by any constraints that
govern the user's privileges.

How could an attacker exploit this vulnerability?
An attacker could seek to exploit this vulnerability by building a web
page that contacts the attacker's server. When the response from the
attacker's server was processed, the buffer would be overrun and the
attacker's code would execute.

In the case of IE, the attacker could either post the web page on a server
or send it as an HTML email. In either instance, as soon as the page was
displayed and the response from the attacker's server received, the attack
would be carried out.

In the case of ISA and Proxy server, a successful attack would require
that the web proxy service receive the malformed Gopher response. In
practical terms, this means that a proxy server client would most likely
have to make a request to the attacker's server. When the server received
and processed the malicious response, the attack would be carried out.

I'm running email in the Restricted Sites zone, am I at risk from this
vulnerability?
While the Restricted Sites zone often provides protection against HTML
email-based vulnerabilities, it does not protect against attempts to
exploit this vulnerability by email. This is because basic HTML
functionality, which is permitted in the Restricted Sites zone, is
sufficient to invoke the vulnerability.

Is there anything that can mitigate against attempts to exploit this
vulnerability by email?
Yes. The "Read as Plan Text" feature in Outlook 2002 SP1 can protect
against attempts to exploit this vulnerability by HTML email. This is
because this feature disables all HTML functionality.

Is there anything that can mitigate against this vulnerability?
Yes. A successful attack requires that the attacker's server be able to
send Gopher traffic to the intended target. Anything which inhibits the
attacker's ability to send Gopher traffic would help protect against this
vulnerability.

Most notably, customers who block access to the Gopher protocol (TCP port
70) at the perimeter firewall would be protected against attempts to
exploit this vulnerability across the Internet.

As Gopher is a legacy protocol, those customers who are not currently
blocking it should consider blocking it permanently as a best practice.

How can I protect against this vulnerability in IE until patches are
completed?
Customers can protect themselves against this vulnerability in IE by
defining a non-functional Gopher proxy in Internet Explorer. This has the
result of essentially disabling the Gopher protocol in IE by making it
impossible for IE to send and receive Gopher traffic.

How can I implement this work-around manually?
Customers can implement the work-around manually by following the steps
listed below:

 * Right Click on Internet Explorer(IE) Icon on the Desktop or while IE is
open, Click on "Tools" and select "Internet Options"
 * Click on the "Connections" Tab
 * Click on the "LAN Settings..." button
   * Uncheck "automatically detect settings"
   * If "automatic configuration script" is set, check with your
administrator if gopher server is called out.
 * Check the "Use proxy server for your LAN..." Checkbox
 * Click on the "Advanced..." button
   * Ensure "use the same proxy server for all protocols" is unchecked.
 * In the "Proxy addresses to use" textbox next to the word Gopher, Type
"LocalHost"
 * In the "Port" textbox next to the Gopher protocol, Type "1"
 * Click 'OK' until the Internet Options Menu disappears.

I am a network administrator, how can I implement this work-around in my
Enterprise?
Administrators can use the "Automatic Proxy Configuration Script" feature
in IE to implement this workaround in a .pac file. Below is an example of
how this could be implemented:
function FindProxyForURL(url, host)
{
if (url.substring(0, 7) == "gopher:") {

return "PROXY localhost:1";
}
else {

return "DIRECT";
}
}

How can I protect against this vulnerability in ISA and Proxy 2.0 Servers?
Customers using these products can protect themselves by disabling the
Gopher protocol.

How can I implement the work-around on an ISA Array?
Customers can implement the work-around on an ISA array by adding a new
protocol rule in the ISA management tool (array level) as listed in the
steps listed below:

 * Go to the node: Servers and Arrays, Array node, Access policy, Protocol
Rules.
 * Select in the menu: "New, Rule..." (this will start a new rule wizard)
 * In the first page set a name for the rule
 * In the rule action page, select "deny"
 * In the protocols page, select "Selected protocols" and then select the
Gopher protocol
 * In the schedule page, select "Always"
 * In the client type select "Any request"
 * In the finish page select "Finish"

How can I implement the work-around on multiple ISA Arrays?
Customers who use the enterprise edition of ISA server can use the
enterprise policy to apply a rule at once on all/part of the arrays in the
organization by adding a new protocol rule in ISA management tool
(enterprise level) as listed in the steps below:

 * Go to the node: Enterprise, Policies, applied enterprise policy,
Protocol Rules.
 * Select in the menu: "New, Rule..." (this will start a new rule wizard)
 * In the first page set a name for the rule
 * In the rule action page, select "deny"
 * In the protocols page, select "Selected protocols" and then select the
Gopher protocol
 * In the schedule page, select "Always"
 * In the client type select "Any request"
 * In the finish page select "Finish"

How can I implement the work-around on Proxy 2.0 Server?
By default, denied to any protocol for any users or group of users on
Proxy 2.0. If you have enabled protocol access for users and want to
exclude Gopher from that access, follow the steps listed below:

 * Click Start, point to Programs, point to Microsoft Proxy Server and
click Microsoft Management Console.
 * Double-click on the computer name.
 * On the right pane double click on the Web Proxy.
 * Use the Web Proxy Permission tab to determine which users or group of
users can access via the protocol.
 * Check-in Enable access control.
 * Ensure the gopher "grant access" list is empty (default).
 * Ensure that the "unlimited access" list is empty.
 * Ensure that the other protocols (WWW, FTP, secure) have the appropriate
access list, probably everyone.
 * Click OK

ADDITIONAL INFORMATION

The information has been provided by
<mailto:0_32396_E51E4D7D-DECD-43AE-9A29-36080E8D4C3C_US@Newsletters.Microsoft.com> Microsoft Product Security.

========================================

This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

Relevant Pages