Matthew Murphy
14/02/06, 17:45
This is a cryptographically signed message in MIME format.
--------------ms080804080008020706070007
Content-Type: multipart/mixed;
boundary="------------060209000204020309050804"
This is a multi-part message in MIME format.
--------------060209000204020309050804
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
My apologies to those who are receiving this late or are otherwise
inconvenienced by the staggered release. I had unexpected, last-minute
travel issues that interfered somewhat with today's release.
Of note since the initial drafting of the advisory is that Microsoft has
released a blog post on the MSRC blog about the vulnerability report,
which can be read here:
http://blogs.technet.com/msrc/archive/2006/02/13/419439.aspx
The technical/strategic points about the exploit that are raised in the
post are indeed accurate (though it references MS05-014, when I believe
the correct reference is MS05-008/MS05-013). The exploit has a greater
dependence on timing than previous, related attacks. As such,
Microsoft's decision not to include this issue in a standalone patch is
seemingly justified at this point. However, the point of disagreement
with Microsoft remains the choice of release *timeline*.
I released the information about this issue to a trusted colleague (Gadi
Evron) for publication today, after what I felt was a reasonable time,
in light of my difficulties obtaining internet access.
Though there are disagreements between myself and Microsoft about the
nature of this vulnerability, I would like to thank Brian Schafer of the
MSRC for adhering to a high level of professionalism and technical
accuracy in that post and for continuing to work with me once it was
made clear that the issue would imminently become public.
Also of note is that there was a typo in the information I provided
originally to SecuriTeam. The proper candidate is CVE-2005-3240, not
*3840* as was originally reported by me. SecurityFocus has also
informed me that my original BID reservation was a casualty of a data
migration and that the proper BID associated with this vulnerability is
now BID 16352, which is public in full detail as of this writing.
There have also been some incorrect reports made to SecuriTeam that this
issue does not affect Windows XP Service Pack 2. These reports are not
correct -- my testing during this investigation was done exclusively on
current installations of Windows 2000 and Windows XP. These systems had
all service packs applied and all updates installed when tests were
performed.
Thanks to Gadi Evron for doing some of my bidding today and taking some
of the heat for my fat-fingers.
The final advisory, corrected with the now-accurate references is
attached with an armored-format PGP signature inline.
- --
"Social Darwinism: Try to make something idiot-proof,
nature will provide you with a better idiot."
-- Michael Holstein
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB5444D38
iD8DBQFD8Shufp4vUrVETTgRA/hpAJ9DobMIa4EH8otBMNlzIPK6RrMGUgCfcrrj
ZI9G00rer59rLkwI5uH0KGQ=
=DQ2a
-----END PGP SIGNATURE-----
--------------060209000204020309050804
Content-Type: text/plain;
name="IE-Advisory-Full.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="IE-Advisory-Full.txt"
Microsoft Internet Explorer Drag-and-Drop Redeux
I. SYNOPSIS
Affected Systems:
* Microsoft Internet Explorer 5.01
* Microsoft Internet Explorer 5.5
* Microsoft Internet Explorer 6.0
- Windows 98
- Windows 98 Second Edition
- Windows Millennium Edition
- Windows 2000
- Windows XP
- Windows Server 2003
Risk: Medium
Impact: Potential remote code execution with some user interaction
Status: Uncoordinated Release
Author: Matthew Murphy (mattmurphy@kc.rr.com)
II. VULNERABILITY OVERVIEW
Microsoft Internet Explorer suffers from a vulnerability in its handling of certain drag-and-drop events. As a result, it is possible for a malicious web site to predict and exploit the timing of a drag-and-drop operation such that any drag operation (in
cluding using scroll-bars) could potentially lead to the installation of arbitrary files in sensitive locations that may enable further system compromise.
III. TECHNICAL DESCRIPTION
As a result of recent updates to its drag-and-drop functionality, Internet Explorer now imposes a rigid set of restrictions on most drag-and-drop sources:
* Input to the browser from other applications is not permitted.
* Dragging an object from inside a frame is not permitted.
* Dragging an HTML element from a top-level window will produce a security warning.
However, certain objects not derived from an HTML document (specifically, file objects within a folder view) remain draggable. This gives rise to a potential race condition in the handling of user input. If an attacker can persuade a user to drag any ob
ject within the top-level window that his/her site is contained in, malicious script can redirect these inputs to other top-level windows, potentially resulting in an unintended consequence such as file installation.
Proof-of-concept code has been developed that utilizes a pop-under window pointing to a malicious file share. This window can be created using window.open() or other stealthier methods that are known to evade Internet Explorer's built-in pop-up blocking.
Focus is then returned to the opening window, where the user is encouraged to drag an object (image, link, etc.) in a seemingly "safe" fashion.
Immediately prior to this object being dragged, a mouseOver event is triggered that enables the attacker to (with a varying degree of success) predict the imminent drag attempt. The pop-under can then be returned to focus by way of a window.blur() execut
ed in the current window. If the timing of the transition is accurate to a margin of error within a user's reaction time threshold, the user will unwittingly initiate a drag of a file from the pop-under instead of the object originally used as a lure by
the attacker.
As soon as it transfers focus, the window with the original interactive content may set a timer (via window.setTimeout()) that returns focus to the window with a simple window.focus() call. After a split-second delay, focus is returned to the interactive
window. At this point, on-demand alteration of CSS attributes can be used to display previously-hidden objects (such as inline frames). These objects serve as "drop target" windows and will initiate the copying of the file dropped from the (presumably
malicious) pop-under window.
While Internet Explorer blocks hiding or resizing of certain "suspect" objects (IFRAMEs, for instance), so-called container objects (DIV, SPAN, etc.) suffer no such restrictions, even when they contain one of the objects in the former category. The proof
-of-concept code as developed simply stores a full-screen inline frame in a container initially marked with the "hidden" visibility style.
The pop-under window, in this instance, would be a folder on a malicious server. This could be accessed via SMB (\\HOSTILESERVER\SHARE), FTP (ftp://hostileserver/somedirectory) or even HTTP (web folders) using certain link behaviors in combination with t
he click() method of a hyperlink object. In the third case, the pop-under would be targeted to an HTML document initally, which would then open the web folder containing hostile content.
The path to the drop target (the hidden frame in the original window) requires a little more creativity. Particularly in Windows XP Service Pack 2, Microsoft has done a fairly good job of locking down access to local resources. The most interesting vect
or for the purposes of this attack is via the network redirector. By using the IP address or machine name of the local system (typically obtainable via any number of means), such as:
\\MACHINENAME\share
It becomes possible to access resources offered by the network redirector on the local system. Of most interest is the "Scheduled Tasks" folder:
\\MACHINENAME\Scheduled Tasks
Items dropped into this folder execute automatically at a system-determined time (3 AM local time in tests on Windows XP Professional Service Pack 2) each day as the user dropping the file. Also of interest are common shares such as the administrative sh
ares (C$, D$, etc.) and typical share names like "SharedDocs" on Windows XP. In most cases, this is at least a partial functional equivalent to local file system access and is not subject to zone restrictions, even on Windows XP Service Pack 2.
IV. IMPACT
A malicious web site, with a minimum of social engineering, may be able to compromise user systems by triggering an unintended installation of malicious software. Typical defense-in-depth measures may mitigate this issue. For those who run Internet Expl
orer with administrative privileges, the impact of any successful exploitation is complete control of the affected system. A malicious web site could install software that would add or delete privileged user accounts, alter, destroy or disclose the conte
nt of personal or otherwise sensitive files, record personal information or any number of other activities.
Users who do not browse with such high levels of privilege would be at a significantly reduced risk from exploitation of this vulnerability. In the case of a user with limited privileges, this vulnerability could only be exploited by an attacker to insta
ll software that executes with the privileges of that user.
V. WORKAROUNDS
The following workarounds are believed at the time of this writing to be effective against the exploitation of this vulnerability in some form:
1. Set a Kill Bit on the Shell.Explorer Control
-----------------------------------------------
Setting a kill bit on this control will prevent Internet Explorer from displaying the rich folder view interface that gives rise to this attack. For more information about setting kill bits, please see Microsoft Knowledge Base Article 240797:
http://support.microsoft.com/kb/240797
The CLSID of this component as deployed on Windows XP is:
{8856F961-340A-11D0-A96B-00C04FD705A2}
Tools to automate the process of setting this kill bit have been provided at:
http://student.missouristate.edu/m/matthew007/tools/shellkill.zip
PGP signature: http://student.missouristate.edu/m/matthew007/tools/shellkill.zip.asc
Included in this archive are an Administrative Template (.adm) and a VBScript file (.vbs) which implement this setting. The Administrative Template also allows an administrator to work around a specific case of functionality loss caused by the implementa
tion of this workaround. Instructions on using both files are contained within the readme file in the archive.
IMPACT: This workaround will cause Internet Explorer to no longer render folder views for local directories, network file shares, FTP directories and web folders by default. The ability to browse FTP directories in Internet Explorer can be restored by cl
earing the "Enable Folder View for FTP Sites" option in Internet Explorer's "Advanced" options. However, this countermeasure is known to expose another security vulnerability that does not appear to have been fixed as of this writing:
http://lists.grok.org.uk/pipermail/full-disclosure/2003-June/005321.html
For ordinary browsing purposes, the Windows Explorer tool is unaffected by this change. This defensive measure has been successfully implemented in at least one commercial software product and tested on a significant scale prior to the release of this ad
visory. Therefore, it is the belief of the author that potential loss of functionality *should* be minimal. As with all measures, you are encouraged to test the impact of this workaround prior to making any decision about deployment.
2. Prevent Automatic Navigation to Local Intranet Zone (Windows XP SP2, Windows Server 2003 SP1)
------------------------------------------------------------------------------------------------
This workaround will prevent internet content in Internet Explorer from automatically navigating to URLs within the Local Intranet Zone. This effectively prevents the introduction of malicious code to the local system via the network redirector. To impl
ement this workaround, follow these steps:
1. In Internet Explorer's Tools menu, choose "Internet Options..."
2. Select the "Security" tab and choose "Local Intranet"
3. Click the "Custom Level" button
4. Set the "Web sites in less privileged content zone can navigate into this zone" setting to "Disable" or "Prompt".
5. Click OK to close any dialogs and optionally, close Internet Explorer.
IMPACT: This workaround will block or prompt before allowing any navigation to LAN resources from the Internet Zone. Direct access to LAN resources continues to function normally. As a result of this workaround, attempts to access local intranet content
(for instance, web applications on corporate intranets) from web sites outside of the LAN will fail or produce prompts, depending upon the chosen setting.
3. Disable Active Scripting
---------------------------
This workaround will prevent internet content from executing script that could potentially cause the exploitation of this vulnerability. To implement this workaround, follow these steps:
1. In Internet Explorer's Tools menu, choose "Internet Options..."
2. Select the "Security" tab and choose "Internet"
3. Click the "Custom Level" button
4. Set the "Active scripting" option to "Prompt" or "Disable".
IMPACT: This workaround will block or prompt before allowing web sites to execute any script statement. Scripting in more-privileged zones (Local Intranet, Trusted Sites) continues to function normally. Setting this option to "Prompt" may cause a signif
icant increase in the number of security prompts received while browsing and may be ineffective in closing this vulnerability for users not capable of making an assessment of a web site's relative trustworthiness.
VI. MITIGATION RECOMMENDATIONS
1. Limit Viewing to Trusted Web Sites
-------------------------------------
In some situations, browsing can be successfully limited to only trustworthy sites without significant loss of productivity. Users should be extremely cautious while browsing unknown or untrusted web sites, as such web sites are often able to introduce h
ostile code.
2. Run Exposed Applications With Reduced Privilege
--------------------------------------------------
Users who log on interactively without the privileges of powerful groups such as the "Administrators" or "Power Users" groups are at a much lower risk of damage from successful exploitation of software vulnerabilities in client applications. This mitigat
ion step greatly reduces the likelihood of a successful malware installation if this vulnerability is exploited.
VII. VENDOR RESPONSE
Microsoft was informed of this vulnerability on August 3, 2005. Currently, the company has no plans to issue a security update to correct this vulnerability. Fixes for this issue are scheduled to be included in Service Pack 2 of Windows Server 2003 and
Service Pack 3 of Windows XP. Of particular note is that Windows 2000 users will *NOT* receive an update to correct this vulnerability.
Microsoft's internal risk-assessment concluded that this issue was not sufficiently serious to be fixed in a security bulletin. This conclusion appears fundamentally inconsistent with the way related issues were handled by Microsoft. In particular, the
drag-and-drop vulnerability patched by MS05-013 received an "Important" rating.
I disagree with the technical conclusion behind Microsoft's decision and I further find the timeframe of delivery and deployment for maintenance releases to be largely unsuitable for security fixes of any significant magnitude. I find the harm this decis
ion could potentially inflict upon down-level users (most importantly, users of Windows 2000) to be unjustified by the technical concern Microsoft has raised to me. Microsoft also rejected a request that it consider the issue for inclusion in a later sec
urity update as a "Moderate" risk issue.
Due to Microsoft's noncommittal and generally unimpressive response to the issue, this advisory is being issued to inform users of this vulnerability such that defensive action may be taken as desired.
VIII. REFERENCES/STANDARDS
* CVE
The MITRE Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2005-3840 to this issue. Status information and related references for this candidate may be found at:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3840
* OSVDB
The Open Source Vulnerability Database (OSVDB) project has assigned OSVDB vulnerability ID #2707 to this issue. Information will be available shortly after the publication of this advisory at the following URL:
http://www.osvdb.org/displayvuln.php?osvdb_id=2707
* SecurityTracker
SecurityTracker has pre-assigned an alert number in its internal database to reference this issue. Information will be available shortly after the publication of this advisory at the following URL:
http://www.securitytracker.com/id?1015049
* SecurityFocus
SecurityFocus has pre-assigned BugTraq ID #15089 to reference this issue. Information will be available shortly after the publication of this advisory at the following URL:
http://www.securityfocus.com/bid/15089
IX. ACKNOWLEDGEMENTS
* The Administrative Template file supplied in the workaround ZIP was authored by Steven Platt.
X. CONTACT
The author may be contacted via e-mail at mattmurphy@kc.rr.com
XI. LEGAL
This document is believed accurate based upon information available at the time it was written. However, the information offered is offered in an AS-IS condition, without warranty. By acting upon this information in any way you accept all responsibility
for damage that may occur as a result.
This document may be reproduced in whole without limitation and in part provided that a full copy of the original document is readily accessible and the author of the document is duly acknowledged.
--------------060209000204020309050804--
--------------ms080804080008020706070007
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCS qGSIb3DQEHAQAAoIIJ8zCC
Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBg NVBAYTAlpBMRUwEwYDVQQI
EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMB gGA1UEChMRVGhhd3RlIENv
bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydm ljZXMgRGl2aXNpb24xJDAi
BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMC kGCSqGSIb3DQEJARYccGVy
c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMD AwMDBaFw0xMzA3MTYyMzU5
NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ2 9uc3VsdGluZyAoUHR5KSBM
dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haW wgSXNzdWluZyBDQTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHm jAdQRwnd/p/6Me7L3N9Vvy
Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNi QqE88r1fOC
dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB
kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh
d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMA sGA1UdDwQEAwIBBjApBgNV
HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMz gwDQYJKoZIhvcNAQEFBQAD
gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi
w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5 Xa9/eH1sYITq726jTlEBpb
NU1341YheILcIRk13iSx0x1G/11fZU8wggNUMIICvaADAgECAgMPac0wDQYJKoZIhvcNAQEE
BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb2 5zdWx0aW5nIChQdHkpIEx0
ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbC BJc3N1aW5nIENBMB4XDTA1
MDkwMjIwNDAwNVoXDTA2MDkwMjIwNDAwNVowgZQxHzAdBgNVBA MTFlRoYXd0ZSBGcmVlbWFp
bCBNZW1iZXIxIzAhBgkqhkiG9w0BCQEWFG1hdHRtdXJwaHlAa2 MucnIuY29tMR8wHQYJKoZI
hvcNAQkBFhBtcm01NjVzQHNtc3UuZWR1MSswKQYJKoZIhvcNAQ kBFhxNYXR0aGV3MDA3QE1p
c3NvdXJpU3RhdGUuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ 8AMIIBCgKCAQEAs9KzYUk0
0k7m341UkZdC1MJvPEhyqEgX6fy6CEqoD6oSKCUK5jqVYOO2xG gHv43mHtLMYb1XzWv+DU3P
SJcEVSQxZRXSAK3XWcr8eS1HeK4HScr3KYwIzJoP4cFkPCBd59 AVILY3j82DZLyIVbNDvX8S
Zw6VitSnmbSX7CM2mKr8AQ7nhwUEi/WzfIxOMp2WHxpYW4chK9bo4fdxUlGg+h6Ji6HrIkHS
N4jkmHDTEqByZzxZj/rhlxXhPMbzR0mAkZPFVOU+kytecxlahK4sH4egxMgUqlyR01z9 Yn+L
DE4rxpIZoDfXBqm0LkSTn3Les+ETxu6SDVEZKKbekcU/VQIDAQABo2EwXzBPBgNVHREESDBG
gRRtYXR0bXVycGh5QGtjLnJyLmNvbYEQbXJtNTY1c0BzbXN1Lm VkdYEcTWF0dGhldzAwN0BN
aXNzb3VyaVN0YXRlLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSI b3DQEBBAUAA4GBAFlgmmxY
Pc1K1wg3JyVJNulCHvHKvaw2zmWgpuBDijSZhZ0GPheKZa/je0oJvqp897AfH9f1tSykdHm2
VcA5QdFN1JFb8AlJDXq68G2MYgQfMyhiAWfhhfCO694JfJqVaY 5onDvfMxD0JpbzD60Efc/6
l1C2IO0zBuzFuho9XvQiMIIDVDCCAr2gAwIBAgIDD2nNMA0GCS qGSIb3DQEBBAUAMGIxCzAJ
BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZy AoUHR5KSBMdGQuMSwwKgYD
VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZy BDQTAeFw0wNTA5MDIyMDQw
MDVaFw0wNjA5MDIyMDQwMDVaMIGUMR8wHQYDVQQDExZUaGF3dG UgRnJlZW1haWwgTWVtYmVy
MSMwIQYJKoZIhvcNAQkBFhRtYXR0bXVycGh5QGtjLnJyLmNvbT EfMB0GCSqGSIb3DQEJARYQ
bXJtNTY1c0BzbXN1LmVkdTErMCkGCSqGSIb3DQEJARYcTWF0dG hldzAwN0BNaXNzb3VyaVN0
YXRlLmVkdTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCgg EBALPSs2FJNNJO5t+NVJGX
QtTCbzxIcqhIF+n8ughKqA+qEiglCuY6lWDjtsRoB7+N5h7SzG G9V81r/g1Nz0iXBFUkMWUV
0gCt11nK/HktR3iuB0nK9ymMCMyaD+HBZDwgXefQFSC2N4/Ng2S8iFWzQ71/EmcOlYrUp5m0
l+wjNpiq/AEO54cFBIv1s3yMTjKdlh8aWFuHISvW6OH3cVJRoPoeiYuh6yJ B0jeI5Jhw0xKg
cmc8WY/64ZcV4TzG80dJgJGTxVTlPpMrXnMZWoSuLB+HoMTIFKpckdNc/WJ/iwxOK8aSGaA3
1waptC5Ek59y3rPhE8bukg1RGSim3pHFP1UCAwEAAaNhMF8wTw YDVR0RBEgwRoEUbWF0dG11
cnBoeUBrYy5yci5jb22BEG1ybTU2NXNAc21zdS5lZHWBHE1hdH RoZXcwMDdATWlzc291cmlT
dGF0ZS5lZHUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBZYJpsWD3NStcINycl
STbpQh7xyr2sNs5loKbgQ4o0mYWdBj4XimWv43tKCb6qfPewHx/X9bUspHR5tlXAOUHRTdSR
W/AJSQ16uvBtjGIEHzMoYgFn4YXwjuveCXyalWmOaJw73zMQ9CaW 8w+tBH3P+pdQtiDtMwbs
xboaPV70IjGCAzswggM3AgEBMGkwYjELMAkGA1UEBhMCWkExJT AjBgNVBAoTHFRoYXd0ZSBD
b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZS BQZXJzb25hbCBGcmVlbWFp
bCBJc3N1aW5nIENBAgMPac0wCQYFKw4DAhoFAKCCAacwGAYJKo ZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwMjE0MDA0NjM4WjAjBg kqhkiG9w0BCQQxFgQUy95B
JPNziLUaU2hdIfTAd8RA27EwUgYJKoZIhvcNAQkPMUUwQzAKBg gqhkiG9w0DBzAOBggqhkiG
9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKo ZIhvcNAwICASgweAYJKwYB
BAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVG hhd3RlIENvbnN1bHRpbmcg
KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIE ZyZWVtYWlsIElzc3Vpbmcg
Q0ECAw9pzTB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBh MCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1 RoYXd0ZSBQZXJzb25hbCBG
cmVlbWFpbCBJc3N1aW5nIENBAgMPac0wDQYJKoZIhvcNAQEBBQ AEggEADkHz8nQcCJcjF6uh
oJ+DYLfL1Yl5nod0yoKjb9IUmo50OrBFhb+1YT0FaZESl408iB eAaRn2uEBifLvJiIyM0TAS
lHG1GW3ROtnMu1g2IhehdoTzD0Nc7AVTzxd4u9jWW89biGQn47 9SjY/oh2sE1Sqxq0S7yAo7
DKeeBm7wa90YAXM1284Lekv4ROWQinP+twyZUMrD8HpAUJjz+Z JoeiAjjsSutrRAGDo/Ccpd
bu3qbGHU4uVEjpGyf3/v4Q+MP9sK14S3QgQu0NyQBm5gjAoHtOTkSLgwLdfEYqnEo18B6 Yx/
TKTZm+pdyReuWb+iziyhtCvXizxWbGTWgkWCSQAAAAAAAA==
--------------ms080804080008020706070007--
--------------ms080804080008020706070007
Content-Type: multipart/mixed;
boundary="------------060209000204020309050804"
This is a multi-part message in MIME format.
--------------060209000204020309050804
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
My apologies to those who are receiving this late or are otherwise
inconvenienced by the staggered release. I had unexpected, last-minute
travel issues that interfered somewhat with today's release.
Of note since the initial drafting of the advisory is that Microsoft has
released a blog post on the MSRC blog about the vulnerability report,
which can be read here:
http://blogs.technet.com/msrc/archive/2006/02/13/419439.aspx
The technical/strategic points about the exploit that are raised in the
post are indeed accurate (though it references MS05-014, when I believe
the correct reference is MS05-008/MS05-013). The exploit has a greater
dependence on timing than previous, related attacks. As such,
Microsoft's decision not to include this issue in a standalone patch is
seemingly justified at this point. However, the point of disagreement
with Microsoft remains the choice of release *timeline*.
I released the information about this issue to a trusted colleague (Gadi
Evron) for publication today, after what I felt was a reasonable time,
in light of my difficulties obtaining internet access.
Though there are disagreements between myself and Microsoft about the
nature of this vulnerability, I would like to thank Brian Schafer of the
MSRC for adhering to a high level of professionalism and technical
accuracy in that post and for continuing to work with me once it was
made clear that the issue would imminently become public.
Also of note is that there was a typo in the information I provided
originally to SecuriTeam. The proper candidate is CVE-2005-3240, not
*3840* as was originally reported by me. SecurityFocus has also
informed me that my original BID reservation was a casualty of a data
migration and that the proper BID associated with this vulnerability is
now BID 16352, which is public in full detail as of this writing.
There have also been some incorrect reports made to SecuriTeam that this
issue does not affect Windows XP Service Pack 2. These reports are not
correct -- my testing during this investigation was done exclusively on
current installations of Windows 2000 and Windows XP. These systems had
all service packs applied and all updates installed when tests were
performed.
Thanks to Gadi Evron for doing some of my bidding today and taking some
of the heat for my fat-fingers.
The final advisory, corrected with the now-accurate references is
attached with an armored-format PGP signature inline.
- --
"Social Darwinism: Try to make something idiot-proof,
nature will provide you with a better idiot."
-- Michael Holstein
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB5444D38
iD8DBQFD8Shufp4vUrVETTgRA/hpAJ9DobMIa4EH8otBMNlzIPK6RrMGUgCfcrrj
ZI9G00rer59rLkwI5uH0KGQ=
=DQ2a
-----END PGP SIGNATURE-----
--------------060209000204020309050804
Content-Type: text/plain;
name="IE-Advisory-Full.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="IE-Advisory-Full.txt"
Microsoft Internet Explorer Drag-and-Drop Redeux
I. SYNOPSIS
Affected Systems:
* Microsoft Internet Explorer 5.01
* Microsoft Internet Explorer 5.5
* Microsoft Internet Explorer 6.0
- Windows 98
- Windows 98 Second Edition
- Windows Millennium Edition
- Windows 2000
- Windows XP
- Windows Server 2003
Risk: Medium
Impact: Potential remote code execution with some user interaction
Status: Uncoordinated Release
Author: Matthew Murphy (mattmurphy@kc.rr.com)
II. VULNERABILITY OVERVIEW
Microsoft Internet Explorer suffers from a vulnerability in its handling of certain drag-and-drop events. As a result, it is possible for a malicious web site to predict and exploit the timing of a drag-and-drop operation such that any drag operation (in
cluding using scroll-bars) could potentially lead to the installation of arbitrary files in sensitive locations that may enable further system compromise.
III. TECHNICAL DESCRIPTION
As a result of recent updates to its drag-and-drop functionality, Internet Explorer now imposes a rigid set of restrictions on most drag-and-drop sources:
* Input to the browser from other applications is not permitted.
* Dragging an object from inside a frame is not permitted.
* Dragging an HTML element from a top-level window will produce a security warning.
However, certain objects not derived from an HTML document (specifically, file objects within a folder view) remain draggable. This gives rise to a potential race condition in the handling of user input. If an attacker can persuade a user to drag any ob
ject within the top-level window that his/her site is contained in, malicious script can redirect these inputs to other top-level windows, potentially resulting in an unintended consequence such as file installation.
Proof-of-concept code has been developed that utilizes a pop-under window pointing to a malicious file share. This window can be created using window.open() or other stealthier methods that are known to evade Internet Explorer's built-in pop-up blocking.
Focus is then returned to the opening window, where the user is encouraged to drag an object (image, link, etc.) in a seemingly "safe" fashion.
Immediately prior to this object being dragged, a mouseOver event is triggered that enables the attacker to (with a varying degree of success) predict the imminent drag attempt. The pop-under can then be returned to focus by way of a window.blur() execut
ed in the current window. If the timing of the transition is accurate to a margin of error within a user's reaction time threshold, the user will unwittingly initiate a drag of a file from the pop-under instead of the object originally used as a lure by
the attacker.
As soon as it transfers focus, the window with the original interactive content may set a timer (via window.setTimeout()) that returns focus to the window with a simple window.focus() call. After a split-second delay, focus is returned to the interactive
window. At this point, on-demand alteration of CSS attributes can be used to display previously-hidden objects (such as inline frames). These objects serve as "drop target" windows and will initiate the copying of the file dropped from the (presumably
malicious) pop-under window.
While Internet Explorer blocks hiding or resizing of certain "suspect" objects (IFRAMEs, for instance), so-called container objects (DIV, SPAN, etc.) suffer no such restrictions, even when they contain one of the objects in the former category. The proof
-of-concept code as developed simply stores a full-screen inline frame in a container initially marked with the "hidden" visibility style.
The pop-under window, in this instance, would be a folder on a malicious server. This could be accessed via SMB (\\HOSTILESERVER\SHARE), FTP (ftp://hostileserver/somedirectory) or even HTTP (web folders) using certain link behaviors in combination with t
he click() method of a hyperlink object. In the third case, the pop-under would be targeted to an HTML document initally, which would then open the web folder containing hostile content.
The path to the drop target (the hidden frame in the original window) requires a little more creativity. Particularly in Windows XP Service Pack 2, Microsoft has done a fairly good job of locking down access to local resources. The most interesting vect
or for the purposes of this attack is via the network redirector. By using the IP address or machine name of the local system (typically obtainable via any number of means), such as:
\\MACHINENAME\share
It becomes possible to access resources offered by the network redirector on the local system. Of most interest is the "Scheduled Tasks" folder:
\\MACHINENAME\Scheduled Tasks
Items dropped into this folder execute automatically at a system-determined time (3 AM local time in tests on Windows XP Professional Service Pack 2) each day as the user dropping the file. Also of interest are common shares such as the administrative sh
ares (C$, D$, etc.) and typical share names like "SharedDocs" on Windows XP. In most cases, this is at least a partial functional equivalent to local file system access and is not subject to zone restrictions, even on Windows XP Service Pack 2.
IV. IMPACT
A malicious web site, with a minimum of social engineering, may be able to compromise user systems by triggering an unintended installation of malicious software. Typical defense-in-depth measures may mitigate this issue. For those who run Internet Expl
orer with administrative privileges, the impact of any successful exploitation is complete control of the affected system. A malicious web site could install software that would add or delete privileged user accounts, alter, destroy or disclose the conte
nt of personal or otherwise sensitive files, record personal information or any number of other activities.
Users who do not browse with such high levels of privilege would be at a significantly reduced risk from exploitation of this vulnerability. In the case of a user with limited privileges, this vulnerability could only be exploited by an attacker to insta
ll software that executes with the privileges of that user.
V. WORKAROUNDS
The following workarounds are believed at the time of this writing to be effective against the exploitation of this vulnerability in some form:
1. Set a Kill Bit on the Shell.Explorer Control
-----------------------------------------------
Setting a kill bit on this control will prevent Internet Explorer from displaying the rich folder view interface that gives rise to this attack. For more information about setting kill bits, please see Microsoft Knowledge Base Article 240797:
http://support.microsoft.com/kb/240797
The CLSID of this component as deployed on Windows XP is:
{8856F961-340A-11D0-A96B-00C04FD705A2}
Tools to automate the process of setting this kill bit have been provided at:
http://student.missouristate.edu/m/matthew007/tools/shellkill.zip
PGP signature: http://student.missouristate.edu/m/matthew007/tools/shellkill.zip.asc
Included in this archive are an Administrative Template (.adm) and a VBScript file (.vbs) which implement this setting. The Administrative Template also allows an administrator to work around a specific case of functionality loss caused by the implementa
tion of this workaround. Instructions on using both files are contained within the readme file in the archive.
IMPACT: This workaround will cause Internet Explorer to no longer render folder views for local directories, network file shares, FTP directories and web folders by default. The ability to browse FTP directories in Internet Explorer can be restored by cl
earing the "Enable Folder View for FTP Sites" option in Internet Explorer's "Advanced" options. However, this countermeasure is known to expose another security vulnerability that does not appear to have been fixed as of this writing:
http://lists.grok.org.uk/pipermail/full-disclosure/2003-June/005321.html
For ordinary browsing purposes, the Windows Explorer tool is unaffected by this change. This defensive measure has been successfully implemented in at least one commercial software product and tested on a significant scale prior to the release of this ad
visory. Therefore, it is the belief of the author that potential loss of functionality *should* be minimal. As with all measures, you are encouraged to test the impact of this workaround prior to making any decision about deployment.
2. Prevent Automatic Navigation to Local Intranet Zone (Windows XP SP2, Windows Server 2003 SP1)
------------------------------------------------------------------------------------------------
This workaround will prevent internet content in Internet Explorer from automatically navigating to URLs within the Local Intranet Zone. This effectively prevents the introduction of malicious code to the local system via the network redirector. To impl
ement this workaround, follow these steps:
1. In Internet Explorer's Tools menu, choose "Internet Options..."
2. Select the "Security" tab and choose "Local Intranet"
3. Click the "Custom Level" button
4. Set the "Web sites in less privileged content zone can navigate into this zone" setting to "Disable" or "Prompt".
5. Click OK to close any dialogs and optionally, close Internet Explorer.
IMPACT: This workaround will block or prompt before allowing any navigation to LAN resources from the Internet Zone. Direct access to LAN resources continues to function normally. As a result of this workaround, attempts to access local intranet content
(for instance, web applications on corporate intranets) from web sites outside of the LAN will fail or produce prompts, depending upon the chosen setting.
3. Disable Active Scripting
---------------------------
This workaround will prevent internet content from executing script that could potentially cause the exploitation of this vulnerability. To implement this workaround, follow these steps:
1. In Internet Explorer's Tools menu, choose "Internet Options..."
2. Select the "Security" tab and choose "Internet"
3. Click the "Custom Level" button
4. Set the "Active scripting" option to "Prompt" or "Disable".
IMPACT: This workaround will block or prompt before allowing web sites to execute any script statement. Scripting in more-privileged zones (Local Intranet, Trusted Sites) continues to function normally. Setting this option to "Prompt" may cause a signif
icant increase in the number of security prompts received while browsing and may be ineffective in closing this vulnerability for users not capable of making an assessment of a web site's relative trustworthiness.
VI. MITIGATION RECOMMENDATIONS
1. Limit Viewing to Trusted Web Sites
-------------------------------------
In some situations, browsing can be successfully limited to only trustworthy sites without significant loss of productivity. Users should be extremely cautious while browsing unknown or untrusted web sites, as such web sites are often able to introduce h
ostile code.
2. Run Exposed Applications With Reduced Privilege
--------------------------------------------------
Users who log on interactively without the privileges of powerful groups such as the "Administrators" or "Power Users" groups are at a much lower risk of damage from successful exploitation of software vulnerabilities in client applications. This mitigat
ion step greatly reduces the likelihood of a successful malware installation if this vulnerability is exploited.
VII. VENDOR RESPONSE
Microsoft was informed of this vulnerability on August 3, 2005. Currently, the company has no plans to issue a security update to correct this vulnerability. Fixes for this issue are scheduled to be included in Service Pack 2 of Windows Server 2003 and
Service Pack 3 of Windows XP. Of particular note is that Windows 2000 users will *NOT* receive an update to correct this vulnerability.
Microsoft's internal risk-assessment concluded that this issue was not sufficiently serious to be fixed in a security bulletin. This conclusion appears fundamentally inconsistent with the way related issues were handled by Microsoft. In particular, the
drag-and-drop vulnerability patched by MS05-013 received an "Important" rating.
I disagree with the technical conclusion behind Microsoft's decision and I further find the timeframe of delivery and deployment for maintenance releases to be largely unsuitable for security fixes of any significant magnitude. I find the harm this decis
ion could potentially inflict upon down-level users (most importantly, users of Windows 2000) to be unjustified by the technical concern Microsoft has raised to me. Microsoft also rejected a request that it consider the issue for inclusion in a later sec
urity update as a "Moderate" risk issue.
Due to Microsoft's noncommittal and generally unimpressive response to the issue, this advisory is being issued to inform users of this vulnerability such that defensive action may be taken as desired.
VIII. REFERENCES/STANDARDS
* CVE
The MITRE Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2005-3840 to this issue. Status information and related references for this candidate may be found at:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3840
* OSVDB
The Open Source Vulnerability Database (OSVDB) project has assigned OSVDB vulnerability ID #2707 to this issue. Information will be available shortly after the publication of this advisory at the following URL:
http://www.osvdb.org/displayvuln.php?osvdb_id=2707
* SecurityTracker
SecurityTracker has pre-assigned an alert number in its internal database to reference this issue. Information will be available shortly after the publication of this advisory at the following URL:
http://www.securitytracker.com/id?1015049
* SecurityFocus
SecurityFocus has pre-assigned BugTraq ID #15089 to reference this issue. Information will be available shortly after the publication of this advisory at the following URL:
http://www.securityfocus.com/bid/15089
IX. ACKNOWLEDGEMENTS
* The Administrative Template file supplied in the workaround ZIP was authored by Steven Platt.
X. CONTACT
The author may be contacted via e-mail at mattmurphy@kc.rr.com
XI. LEGAL
This document is believed accurate based upon information available at the time it was written. However, the information offered is offered in an AS-IS condition, without warranty. By acting upon this information in any way you accept all responsibility
for damage that may occur as a result.
This document may be reproduced in whole without limitation and in part provided that a full copy of the original document is readily accessible and the author of the document is duly acknowledged.
--------------060209000204020309050804--
--------------ms080804080008020706070007
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCS qGSIb3DQEHAQAAoIIJ8zCC
Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBg NVBAYTAlpBMRUwEwYDVQQI
EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMB gGA1UEChMRVGhhd3RlIENv
bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydm ljZXMgRGl2aXNpb24xJDAi
BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMC kGCSqGSIb3DQEJARYccGVy
c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMD AwMDBaFw0xMzA3MTYyMzU5
NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ2 9uc3VsdGluZyAoUHR5KSBM
dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haW wgSXNzdWluZyBDQTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHm jAdQRwnd/p/6Me7L3N9Vvy
Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNi QqE88r1fOC
dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB
kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh
d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMA sGA1UdDwQEAwIBBjApBgNV
HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMz gwDQYJKoZIhvcNAQEFBQAD
gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi
w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5 Xa9/eH1sYITq726jTlEBpb
NU1341YheILcIRk13iSx0x1G/11fZU8wggNUMIICvaADAgECAgMPac0wDQYJKoZIhvcNAQEE
BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb2 5zdWx0aW5nIChQdHkpIEx0
ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbC BJc3N1aW5nIENBMB4XDTA1
MDkwMjIwNDAwNVoXDTA2MDkwMjIwNDAwNVowgZQxHzAdBgNVBA MTFlRoYXd0ZSBGcmVlbWFp
bCBNZW1iZXIxIzAhBgkqhkiG9w0BCQEWFG1hdHRtdXJwaHlAa2 MucnIuY29tMR8wHQYJKoZI
hvcNAQkBFhBtcm01NjVzQHNtc3UuZWR1MSswKQYJKoZIhvcNAQ kBFhxNYXR0aGV3MDA3QE1p
c3NvdXJpU3RhdGUuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ 8AMIIBCgKCAQEAs9KzYUk0
0k7m341UkZdC1MJvPEhyqEgX6fy6CEqoD6oSKCUK5jqVYOO2xG gHv43mHtLMYb1XzWv+DU3P
SJcEVSQxZRXSAK3XWcr8eS1HeK4HScr3KYwIzJoP4cFkPCBd59 AVILY3j82DZLyIVbNDvX8S
Zw6VitSnmbSX7CM2mKr8AQ7nhwUEi/WzfIxOMp2WHxpYW4chK9bo4fdxUlGg+h6Ji6HrIkHS
N4jkmHDTEqByZzxZj/rhlxXhPMbzR0mAkZPFVOU+kytecxlahK4sH4egxMgUqlyR01z9 Yn+L
DE4rxpIZoDfXBqm0LkSTn3Les+ETxu6SDVEZKKbekcU/VQIDAQABo2EwXzBPBgNVHREESDBG
gRRtYXR0bXVycGh5QGtjLnJyLmNvbYEQbXJtNTY1c0BzbXN1Lm VkdYEcTWF0dGhldzAwN0BN
aXNzb3VyaVN0YXRlLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSI b3DQEBBAUAA4GBAFlgmmxY
Pc1K1wg3JyVJNulCHvHKvaw2zmWgpuBDijSZhZ0GPheKZa/je0oJvqp897AfH9f1tSykdHm2
VcA5QdFN1JFb8AlJDXq68G2MYgQfMyhiAWfhhfCO694JfJqVaY 5onDvfMxD0JpbzD60Efc/6
l1C2IO0zBuzFuho9XvQiMIIDVDCCAr2gAwIBAgIDD2nNMA0GCS qGSIb3DQEBBAUAMGIxCzAJ
BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZy AoUHR5KSBMdGQuMSwwKgYD
VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZy BDQTAeFw0wNTA5MDIyMDQw
MDVaFw0wNjA5MDIyMDQwMDVaMIGUMR8wHQYDVQQDExZUaGF3dG UgRnJlZW1haWwgTWVtYmVy
MSMwIQYJKoZIhvcNAQkBFhRtYXR0bXVycGh5QGtjLnJyLmNvbT EfMB0GCSqGSIb3DQEJARYQ
bXJtNTY1c0BzbXN1LmVkdTErMCkGCSqGSIb3DQEJARYcTWF0dG hldzAwN0BNaXNzb3VyaVN0
YXRlLmVkdTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCgg EBALPSs2FJNNJO5t+NVJGX
QtTCbzxIcqhIF+n8ughKqA+qEiglCuY6lWDjtsRoB7+N5h7SzG G9V81r/g1Nz0iXBFUkMWUV
0gCt11nK/HktR3iuB0nK9ymMCMyaD+HBZDwgXefQFSC2N4/Ng2S8iFWzQ71/EmcOlYrUp5m0
l+wjNpiq/AEO54cFBIv1s3yMTjKdlh8aWFuHISvW6OH3cVJRoPoeiYuh6yJ B0jeI5Jhw0xKg
cmc8WY/64ZcV4TzG80dJgJGTxVTlPpMrXnMZWoSuLB+HoMTIFKpckdNc/WJ/iwxOK8aSGaA3
1waptC5Ek59y3rPhE8bukg1RGSim3pHFP1UCAwEAAaNhMF8wTw YDVR0RBEgwRoEUbWF0dG11
cnBoeUBrYy5yci5jb22BEG1ybTU2NXNAc21zdS5lZHWBHE1hdH RoZXcwMDdATWlzc291cmlT
dGF0ZS5lZHUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBZYJpsWD3NStcINycl
STbpQh7xyr2sNs5loKbgQ4o0mYWdBj4XimWv43tKCb6qfPewHx/X9bUspHR5tlXAOUHRTdSR
W/AJSQ16uvBtjGIEHzMoYgFn4YXwjuveCXyalWmOaJw73zMQ9CaW 8w+tBH3P+pdQtiDtMwbs
xboaPV70IjGCAzswggM3AgEBMGkwYjELMAkGA1UEBhMCWkExJT AjBgNVBAoTHFRoYXd0ZSBD
b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZS BQZXJzb25hbCBGcmVlbWFp
bCBJc3N1aW5nIENBAgMPac0wCQYFKw4DAhoFAKCCAacwGAYJKo ZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwMjE0MDA0NjM4WjAjBg kqhkiG9w0BCQQxFgQUy95B
JPNziLUaU2hdIfTAd8RA27EwUgYJKoZIhvcNAQkPMUUwQzAKBg gqhkiG9w0DBzAOBggqhkiG
9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKo ZIhvcNAwICASgweAYJKwYB
BAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVG hhd3RlIENvbnN1bHRpbmcg
KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIE ZyZWVtYWlsIElzc3Vpbmcg
Q0ECAw9pzTB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBh MCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1 RoYXd0ZSBQZXJzb25hbCBG
cmVlbWFpbCBJc3N1aW5nIENBAgMPac0wDQYJKoZIhvcNAQEBBQ AEggEADkHz8nQcCJcjF6uh
oJ+DYLfL1Yl5nod0yoKjb9IUmo50OrBFhb+1YT0FaZESl408iB eAaRn2uEBifLvJiIyM0TAS
lHG1GW3ROtnMu1g2IhehdoTzD0Nc7AVTzxd4u9jWW89biGQn47 9SjY/oh2sE1Sqxq0S7yAo7
DKeeBm7wa90YAXM1284Lekv4ROWQinP+twyZUMrD8HpAUJjz+Z JoeiAjjsSutrRAGDo/Ccpd
bu3qbGHU4uVEjpGyf3/v4Q+MP9sK14S3QgQu0NyQBm5gjAoHtOTkSLgwLdfEYqnEo18B6 Yx/
TKTZm+pdyReuWb+iziyhtCvXizxWbGTWgkWCSQAAAAAAAA==
--------------ms080804080008020706070007--