[squid-users] Gopher

Squid can block Gopher protocol?

Microsoft Security Bulletin MS02-027 Print

Unchecked Buffer in Gopher Protocol Handler Can Run Code of Attacker's
Choice (Q323889)
Originally posted: June 11, 2002
Revised: June 14, 2002

Summary
Who should read this bulletin: Customers using Microsoft(r) Internet
Explorer; System administrators running Microsoft Internet Security and
Acceleration (ISA) Server 2000 or Microsoft Proxy Server 2.0.

Impact of vulnerability: Run Code of Attacker's Choice.

Maximum Severity Rating: Critical

Recommendation: Administrators of ISA Server 2000 and Proxy Server 2.0
systems should apply the patch. Customers using IE should implement the
workaround detailed in the FAQ.

Affected Software:

Microsoft Internet Explorer
Microsoft Proxy Server 2.0
Microsoft ISA Server 2000

 Technical details
Technical description:

On June 11, 2002, Microsoft released the original version of this bulletin.
In it, we detailed a work-around procedure that customers could implement to
protect themselves against a publicly disclosed vulnerability. An updated
version of this bulletin was rereleased on June 14, 2002 to announce the
availability of patches for Proxy Server 2.0 and ISA Server 2000 and to
advise customers that the work-around procedure is no longer needed on those
platforms. Patches for IE are forthcoming and this bulletin will be
re-released to announce their availability.

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. Anything which inhibited 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.

Mitigating factors:

A successful attack requires that the attacker's server be able to deliver
information to the target.
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.
Severity Rating: Internet Servers Intranet Servers Client Systems
Internet Explorer 5.01 Moderate Moderate Critical
Internet Explorer 5.5 Moderate Moderate Critical
Internet Explorer 6.0 Moderate Moderate Critical
Proxy Server 2.0 Critical Critical None
ISA Server 2000 Critical Critical None
The above assessment is based on the types of systems affected by the
vulnerability, their typical deployment patterns, and the effect that
exploiting the vulnerability would have on them. In the case of ISA and
Proxy servers, the vulnerability can be used to gain LocalSystem level
access. In the case of IE, the vulnerability can be used to run code in the
user's security context.

Vulnerability identifier: CAN-2002-0371

Tested Versions:
Microsoft tested ISA Server 2000, Microsoft 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.

The following table indicates which of the currently supported versions of
Internet Explorer are affected by the vulnerabilities. Versions of IE prior
to 5.01 Service Pack 2 are no longer eligible for hotfix support. IE 5.01
SP2 is supported only via Windows(r) 2000 Service Packs and Security Roll-up
Packages.
 IE 5.01 SP2 IE 5.5 SP1 IE 5.5 SP2 IE 6.0
Buffer Overrun in Gopher Protocol Handler (CVE-CAN-2002-0371) Yes Yes Yes
Yes

 Frequently asked questions
Why is Microsoft re-releasing this bulletin?

Microsoft originally released this bulletin on June 11, 2002 to advise
customers of work-around procedures that could be used while patches were
under development. On June 14, 2002 Microsoft completed development of
patches for ISA Server 2000 and Proxy Server 2.0 and rereleased this
bulletin to advise customers of their availability. Patches for IE are under
development and will be made available 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's 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 Plain 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
network traffic to the intended target. Anything which inhibits the
attacker's ability to send traffic would help protect against this
vulnerability.

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"
Enter proxy information for any other protocols (FTP, HTTP) in the
appropriate textboxes.
Click 'OK' until the Internet Options Menu disappears.
Note that after unchecking "automatically detect settings" you will need to
ensure that there are entries for other protocols such as HTTP and FTP. If
these boxes are empty, applications that use these protocols may no longer
function correctly.

I'm 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).toLowerCase() == "gopher:") {

return "PROXY localhost:1";
}
else {

return "DIRECT";
}
}
Note that customers using a specific proxy should modify the line: return
"DIRECT" ; to return "PROXY ;"

What do the ISA Server and Proxy Server 2.0 patches do?

The patch eliminates the vulnerability by implementing proper checking on
the buffer that handles server responses.

I implemented the work-around on my ISA Servers, how do I re-enable the
Gopher protocol?

Customers who implemented the work-around on an ISA array can re-enable the
Gopher protocol by deleting the rule that they created by follow the steps
listed below:

Go to the node: Servers and Arrays, Array node, Access policy, Protocol
Rules.
Select rule created to implement the work-around. Select "Delete"
Customer using the enterprise edition of ISA server who implemented the
work-around using the enterprise policy can re-enable the Gopher protocol by
deleting the rule that they created by follow the steps listed below:

Go to the node: Enterprise, Policies, applied enterprise policy, Protocol
Rules.
Select rule created to implement the work-around. Select "Delete"

I implemented the work-around on my Proxy 2.0 Servers, how do I re-enable
the Gopher protocol?

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 has the appropriate access list,
probably everyone.
OR, Ensure that the "unlimited access" list has the appropriate access list.

Click OK

Patch availability
Download locations for this patch
ISA Server 2000:
http://www.microsoft.com/downloads/release.asp?ReleaseID=39856
Proxy Server 2.0:
http://www.microsoft.com/downloads/release.asp?ReleaseID=39861
Internet Explorer:
Patches are under development and will be posted as soon as they are
completed.

 Additional information about this patch
Installation platforms:

The ISA Server 2000 patch can be installed on systems running ISA Server
2000 SP1.
The Proxy Server 2.0 patch can be installed on systems running Proxy Server
2.0 SP 1.
Inclusion in future service packs:
The fix for this issue will be included in ISA Server 2000 SP2

Reboot needed:

ISA Server 2000: No
Proxy Server 2.0: Yes
Superseded patches: None.

Verifying patch installation:

ISA Server 2000 and Proxy Server 2.0:
Verify the file versions as indicated in the file manifest in Q323889
Caveats:
None

Localization:
Localized versions of this patch are available at the locations discussed in
"Obtaining other security patches".

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

All patches available via WindowsUpdate also are available in a
redistributable form from the WindowsUpdate Corporate site.
Other information:
Support:

Microsoft Knowledge Base article Q323889 discusses 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 (June 11, 2002): Bulletin Created.
V2.0 (June 14, 2002): Bulletin updated to include patch availability for ISA
Server 2000 and Proxy Server 2.0 and to correct factual error regarding the
efficacy of blocking port 70.
Received on Mon Jun 17 2002 - 09:54:51 MDT