{"id": "TALOS-2016-0197", "bulletinFamily": "info", "title": "Ichitaro Office Excel File Code Execution Vulnerability", "description": "# Talos Vulnerability Report\n\n### TALOS-2016-0197\n\n## Ichitaro Office Excel File Code Execution Vulnerability\n\n##### February 27, 2017\n\n##### CVE Number\n\nCVE-2017-2790\n\n### Summary\n\nA vulnerability was discovered within the Ichitaro word processor. Ichitaro is published by JustSystems and is considered one of the more popular word processors used within Japan. Ichitaro handles Microsoft Excel\u2019s .xls file format. When processing a record type of 0x3c from a Workbook stream from an .xls, the application trusts that the size is greater than zero, subtracts one from the length, and uses this result as the size for a memcpy. This results in a heap-based buffer overflow and can lead to code-execution under the context of the application.\n\n### Tested Versions\n\nJustSystems Ichitaro\n\n### Product URLs\n\nhttp://www.ichitaro.com/\n\n### CVSSv3 Score\n\n8.8 - CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H\n\n### Details\n\nThis vulnerability revolves around an unchecked integer underflow of the size of a Record of type 0x3c within a Workbook stream in an .xls file handled by Ichitaro.\n\nThe modules involved in the vulnerability are below (as described by `lm vm` in windbg):\n \n \n start end module name\n 44aa0000 44ba3000 JCXCALC C (export symbols) C:\\Program Files (x86)\\JustSystems\\JSLIB32\\JCXCALC.DLL\n File version: 6.0.11.0\n Product version: 6.0.11.0\n \n\nWhile reading a record of type 0x3c, the application calculates the number of bytes it needs to copy into memory. This calculation involves subtracting one from a value read from the file itself (offset 0x1afef in the provided sample) causing an integer underflow.\n \n \n JCXCALC!JCXCCALC_Jsfc_ExConvert+0xa4b1e:\n 44b48cda 8b461e mov eax,dword ptr [esi+1Eh] // File data from 0x3c Record\n 44b48cdd 668b4802 mov cx,word ptr [eax+2] // Size from file (in our case 0)\n ...\n 44b48ce4 6649 dec cx // Underflow the 0 to be 0xffff\n ...\n 44b48ce8 894d08 mov dword ptr [ebp+8],ecx // Store the 0xffff for later use\n \n\nLater in the same function, this underflowed value is passed to the function handling the copying of file data.\n \n \n JCXCALC!JCXCCALC_Jsfc_ExConvert+0xa4b46:\n 44b48d04 0fb75508 movzx edx,word ptr [ebp+8] // Store 0xffff into edx\n ...\n 44b48d1f 52 push edx // Push size\n 44b48d20 51 push ecx // Push destination address\n 44b48d21 83c005 add eax,5\n 44b48d24 52 push edx // Push size\n 44b48d25 50 push eax // Push source address\n 44b48d26 e8c5f7ffff call JCXCALC!JCXCCALC_Jsfc_ExConvert+0xa4334 (44b484f0)\n \n\nThe main copy function does have a check to ensure that the size is greater than zero. The underflow value flys under the radar though and passes all checks. Below is the copy function commented with relevant variable names. Note, due to the same register being pushed in the above assembly, both `size` and `size_` in the below C code are equal.\n \n \n int JCXCALC!JCXCCALC_Jsfc_ExConvert+0xa4334(int src, int size, int dst, int size_)\n {\n int result;\n \n result = 0;\n \n if ( !size_ )\n return size;\n if ( size > size_ )\n return 0;\n if ( size > 0 )\n {\n result = size;\n do\n {\n *dst = *src++;\n ++dst;\n --size;\n }\n while ( size );\n }\n return result;\n }\n \n\nThe `dst` address is an allocation with size also from the file of the surrounding element with type `0x1b6` (offset 0x1afe5 in the provided sample). This size is multiplied by 2 before being passed to a `malloc`.\n \n \n JCXCALC!JCXCCALC_Jsfc_ExConvert+0xa4a1c:\n 442c8bd8 668b470e mov ax,word ptr [edi+0Eh] // Size from 0x1b6 element\n 442c8bdc 50 push eax\n 442c8bdd e88b87f6ff call JCXCALC!JCXCCALC_Jsfc_ExConvert+0xd1b1 (4423136d)\n \n JCXCALC!JCXCCALC_Jsfc_ExConvert+0xd1b1:\n 4423136d 0fb7442404 movzx eax,word ptr [esp+4]\n 44231372 d1e0 shl eax,1\n 44231374 50 push eax\n 44231375 ff1580d42f44 call ds:malloc\n 4423137b 59 pop ecx\n 4423137c c3 ret\n \n\nNow that an attacker can control both the size of the allocation, trusted from the file, and the size of a memcpy, by leveraging an integer underflow, a heap-based buffer overflow can occur, which can lead to arbitary code execution.\n\n### Timeline\n\n2016-08-29 - Vendor Disclosure \n2017-02-24 - Public Release \n\n\n##### Credit\n\nDiscovered by a Talos team member and Cory Duplantis of Cisco Talos.\n\n* * *\n\nVulnerability Reports Next Report\n\nTALOS-2016-0260\n\nPrevious Report\n\nTALOS-2016-0210\n", "published": "2017-02-27T00:00:00", "modified": "2017-02-27T00:00:00", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}, "href": "http://www.talosintelligence.com/vulnerability_reports/TALOS-2016-0197", "reporter": "Talos Intelligence", "references": [], "cvelist": ["CVE-2017-2790"], "type": "talos", "lastseen": "2020-07-01T21:25:19", "edition": 12, "viewCount": 9, "enchantments": {"dependencies": {"references": [{"type": "cve", "idList": ["CVE-2017-2790"]}, {"type": "seebug", "idList": ["SSV:96563"]}, {"type": "myhack58", "idList": ["MYHACK58:62201784571", "MYHACK58:62201784549"]}], "modified": "2020-07-01T21:25:19", "rev": 2}, "score": {"value": 6.6, "vector": "NONE", "modified": "2020-07-01T21:25:19", "rev": 2}, "vulnersScore": 6.6}, "scheme": null}

{"cve": [{"lastseen": "2020-10-03T13:07:42", "description": "When processing a record type of 0x3c from a Workbook stream from an Excel file (.xls), JustSystems Ichitaro Office trusts that the size is greater than zero, subtracts one from the length, and uses this result as the size for a memcpy. This results in a heap-based buffer overflow and can lead to code execution under the context of the application.", "edition": 3, "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 9.8, "privilegesRequired": "NONE", "vectorString": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.0"}, "impactScore": 5.9}, "published": "2017-02-24T22:59:00", "title": "CVE-2017-2790", "type": "cve", "cwe": ["CWE-119"], "bulletinFamily": "NVD", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 7.5, "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 6.4, "obtainUserPrivilege": false}, "cvelist": ["CVE-2017-2790"], "modified": "2017-03-02T15:41:00", "cpe": ["cpe:/a:justsystems:ichitaro:*"], "id": "CVE-2017-2790", "href": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-2790", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}, "cpe23": ["cpe:2.3:a:justsystems:ichitaro:*:*:*:*:*:*:*:*"]}], "seebug": [{"lastseen": "2017-11-19T12:00:55", "description": "### Summary\r\nA vulnerability was discovered within the Ichitaro word processor. Ichitaro is published by JustSystems and is considered one of the more popular word processors used within Japan. Ichitaro handles Microsoft Excel's .xls file format. When processing a record type of 0x3c from a Workbook stream from an .xls, the application trusts that the size is greater than zero, subtracts one from the length, and uses this result as the size for a memcpy. This results in a heap-based buffer overflow and can lead to code-execution under the context of the application.\r\n\r\n### Tested Versions\r\nJustSystems Ichitaro\r\n\r\n### Product URLs\r\nhttp://www.ichitaro.com/\r\n\r\n### CVSSv3 Score\r\n8.8 - CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H\r\n\r\n### Details\r\nThis vulnerability revolves around an unchecked integer underflow of the size of a Record of type 0x3c within a Workbook stream in an .xls file handled by Ichitaro.\r\nThe modules involved in the vulnerability are below (as described by `lm vm` in windbg):\r\n```\r\nstart end module name\r\n44aa0000 44ba3000 JCXCALC C (export symbols) C:\\Program Files (x86)\\JustSystems\\JSLIB32\\JCXCALC.DLL\r\n File version: 6.0.11.0\r\n Product version: 6.0.11.0\r\n```\r\n\r\nWhile reading a record of type 0x3c, the application calculates the number of bytes it needs to copy into memory. This calculation involves subtracting one from a value read from the file itself (offset 0x1afef in the provided sample) causing an integer underflow.\r\n```\r\nJCXCALC!JCXCCALC_Jsfc_ExConvert+0xa4b1e:\r\n44b48cda 8b461e mov eax,dword ptr [esi+1Eh] // File data from 0x3c Record\r\n44b48cdd 668b4802 mov cx,word ptr [eax+2] // Size from file (in our case 0)\r\n...\r\n44b48ce4 6649 dec cx // Underflow the 0 to be 0xffff\r\n...\r\n44b48ce8 894d08 mov dword ptr [ebp+8],ecx // Store the 0xffff for later use\r\n```\r\n\r\nLater in the same function, this underflowed value is passed to the function handling the copying of file data.\r\n```\r\nJCXCALC!JCXCCALC_Jsfc_ExConvert+0xa4b46:\r\n44b48d04 0fb75508 movzx edx,word ptr [ebp+8] // Store 0xffff into edx\r\n...\r\n44b48d1f 52 push edx // Push size\r\n44b48d20 51 push ecx // Push destination address\r\n44b48d21 83c005 add eax,5\r\n44b48d24 52 push edx // Push size\r\n44b48d25 50 push eax // Push source address\r\n44b48d26 e8c5f7ffff call JCXCALC!JCXCCALC_Jsfc_ExConvert+0xa4334 (44b484f0)\r\n```\r\n\r\nThe main copy function does have a check to ensure that the size is greater than zero. The underflow value flys under the radar though and passes all checks. Below is the copy function commented with relevant variable names. Note, due to the same register being pushed in the above assembly, both `size` and `size_ in` the below C code are equal.\r\n```\r\nint JCXCALC!JCXCCALC_Jsfc_ExConvert+0xa4334(int src, int size, int dst, int size_)\r\n{\r\n int result;\r\n\r\n result = 0;\r\n\r\n if ( !size_ )\r\n return size;\r\n if ( size > size_ )\r\n return 0;\r\n if ( size > 0 )\r\n {\r\n result = size;\r\n do\r\n {\r\n *dst = *src++;\r\n ++dst;\r\n --size;\r\n }\r\n while ( size );\r\n }\r\n return result;\r\n}\r\n```\r\n\r\n\r\nThe `dst` address is an allocation with size also from the file of the surrounding element with type `0x1b6` (offset 0x1afe5 in the provided sample). This size is multiplied by 2 before being passed to a `malloc`.\r\n```\r\nJCXCALC!JCXCCALC_Jsfc_ExConvert+0xa4a1c:\r\n442c8bd8 668b470e mov ax,word ptr [edi+0Eh] // Size from 0x1b6 element\r\n442c8bdc 50 push eax\r\n442c8bdd e88b87f6ff call JCXCALC!JCXCCALC_Jsfc_ExConvert+0xd1b1 (4423136d)\r\n\r\nJCXCALC!JCXCCALC_Jsfc_ExConvert+0xd1b1:\r\n4423136d 0fb7442404 movzx eax,word ptr [esp+4]\r\n44231372 d1e0 shl eax,1\r\n44231374 50 push eax\r\n44231375 ff1580d42f44 call ds:malloc\r\n4423137b 59 pop ecx\r\n4423137c c3 ret\r\n```\r\n\r\nNow that an attacker can control both the size of the allocation, trusted from the file, and the size of a memcpy, by leveraging an integer underflow, a heap-based buffer overflow can occur, which can lead to arbitary code execution.\r\n### Timeline\r\n* 2016-08-29 - Vendor Disclosure \r\n* 2017-02-24 - Public Release \r\n\r\n### CREDIT\r\n* Discovered by a Talos team member and Cory Duplantis of Cisco Talos.", "published": "2017-09-22T00:00:00", "type": "seebug", "title": "Ichitaro Office Excel File Code Execution Vulnerability(CVE-2017-2790)", "bulletinFamily": "exploit", "cvelist": ["CVE-2017-2790"], "modified": "2017-09-22T00:00:00", "href": "https://www.seebug.org/vuldb/ssvid-96563", "id": "SSV:96563", "sourceData": "", "cvss": {"score": 7.5, "vector": "AV:NETWORK/AC:LOW/Au:NONE/C:PARTIAL/I:PARTIAL/A:PARTIAL/"}, "sourceHref": ""}], "myhack58": [{"lastseen": "2017-03-23T07:22:51", "bulletinFamily": "info", "cvelist": ["CVE-2017-2790"], "edition": 1, "description": "#### Overview\n\nWord processing and work product in the vulnerability is the threat actors to exploit the useful target. Users often encounter in everyday life these software packages use the file type, and may in the email to open such a file, or be prompted to download from the website this file does not produce suspicion.\n\nSome of the word processing software in the use of specific language in the community is widely used, but in other places, but little known. For example, Hancom Hangul word processing tools in South Korea widely used, from JustSystems's Ichitaro Office Suite is widely used in Japan and the Japanese-Speaking communities. The use of these software and other similar word processing system of the vulnerability, an attacker can attack the target location to a specific country or its intended victim's language community. Presumably, the attacker may believe, these system attacks are likely not too will be safe the researchers found, because they may lack the exploits of the necessary software.\n\nRecently, Talos found 2 A use of the Hangul word processing tools to complex attacks. <http://blog.talosintelligence.com/2017/02/korean-maldoc.html>, which emphasizes the attacker can create a malicious file with the necessary technology, and this malicious file is designed to aim its office software Suite.\n\nTalos in Ichitaro Office Suite found three vulnerabilities, which software is Japanese most popular word processing program.\n\nThere is no indication that we are in Ichitaro Office Suite in the discovery of three vulnerabilities in any of the one already in the wild being used. However, these three kinds of vulnerability can cause an arbitrary code execution. We chose these vulnerabilities in a to explain in more detail how to exploit such a vulnerability, and by starting the calc. exe to demonstrate remote code execution meaning.\n\nAbout this particular vulnerability of the recommendations, please visit <http://www.talosintelligence.com/reports/TALOS-2016-0197>\n\nIn-depth exploration of - TALOS-2016-0197\uff08CVE-2017-2790 - the JUSTSYSTEMS ICHITARO OFFICE EXCEL file code execution vulnerability\n\nThis vulnerability revolves around an unchecked integer underflow problem, the problem is because the Ichitaro processing XLS files to a workbook within the stream type is 0x3c when recording is not strictly check its length.\n\nRead in next record of type 0x3c, app calculation needs to be copied to memory in number of bytes. This calculation relates to from the file itself to read the value of subtracting a value, which led to an integer underflow.\n\n\nJCXCALC! JCXCCALC_Jsfc_ExConvert+0xa4b1e:\n44b48cda 8b461e mov eax,dword ptr [esi+1Eh] // next record of the file data\n44b48cdd 668b4802 mov cx,word ptr [eax+2] // taken from the file's record length(in our case 0)\n...\n44b48ce4 6649 dec cx // 0 underflow to 0xffff\n...\n44b48ce8 894d08 mov dword ptr [ebp+8],ecx // save the value 0xffff behind the use of\n\nLater in the same function, the underflow value is passed to the processing file data Copy Function. \n\nJCXCALC it! JCXCCALC_Jsfc_ExConvert + 0xa4b46: the\n\n\n44b48d04 0fb75508 movzx edx, word ptr [ebp + 8] //0xffff is stored into edx\n... ...\n44b48d1f 52 push edx //is pressed into the length of the\n44b48d20 51 push ecx //is pressed into the destination address\n44b48d21 83c005 add eax, 5 the\n44b48d24 52 push edx //is pressed into the length of the\n44b48d25 50 push eax //is pressed into the source address\n44b48d26 e8c5f7ffff call JCXCALC it! JCXCCALC_Jsfc_ExConvert + 0xa4334\uff0844b484f0\uff09\n\nThe main copy function does have a check to make sure that the length is greater than zero. Underflow the value of fly under the radar and pass all checks. The following is a use associated variable name comment the Copy Function. Note that, since in the above-described assemblies is pressed into the same register, the following C-code in the size and size_ are equal.\n\n\nint JCXCALC! JCXCCALC_Jsfc_ExConvert+0xa4334(int src, int size, int dst, int size_)\n{\nint result; \nresult = 0;\nif ( ! size_ )\nreturn size;\nif ( size > size_ )\nreturn 0;\nif ( size > 0 )\n{\nresult = size;\ndo\n{\n*dst = *src++;\n++dst;\n--size;\n}\nwhile ( size );\n}\nreturn result;\n}\n\nthe dst address is the address to the allocated memory, its size is also taken from the files of the TxO Record Type 0x1b6 it. This size is passed to malloc prior to the first multiplied by 2.\n\n\nJCXCALC it! JCXCCALC_Jsfc_ExConvert + 0xa4a1c: the\n442c8bd8 668b470e mov ax, word ptr [edi + 0Eh] //from a TxO the size of the element\n442c8bdc 50 push eax\n442c8bdd e88b87f6ff call JCXCALC it! JCXCCALC_Jsfc_ExConvert + 0xd1b1\uff084423136d\uff09\nJCXCALC it! JCXCCALC_Jsfc_ExConvert + 0xd1b1: the\n4423136d 0fb7442404 movzx eax, word ptr [esp + 4]\n44231372 d1e0 shl eax, 1 in //attacker size* 2\n44231374 50 push eax\n44231375 ff1580d42f44 call ds: malloc //controlled malloc\n4423137b 59 pop ecx\n4423137c c3 ret\n\nAll in all, the vulnerability to an attacker provides the following structure:\n\n\n*Memory allocation length is controlled by the value multiplied by 2\n*memcpy into a length of 0xffff in the memory allocation, the value is from the attacker-controlled file data to obtain the\n\nCoverage of the target\n\nIf we want to on Windows 7 to exploit this vulnerability, the question now becomes, using memcpy coverage of Best goals? One approach might be to try to use virtual function overrides object's vtable, so we can use the user control's pointer to control the program counter.\n\nIn order to make the above become feasible, we need to use the following parameters to create:\n\n\n*The object must be to be predicted the size of the allocation to the heap area\n*The object must use a virtual function and has virtual table vtable to.\n*The object must be in coverage occurs after being destroyed.\n\nThe XLS file consists of a plurality of document streams, where each stream are divided into different records. Each record can be described as a type - length - value TLV\uff09structure. This means that each record will be the first few bytes specify its type, followed by the length of the record, the last is included in the recording by the length of the specified bytes of data.\n\nA small figure as shown below: \n\n\n+ ------ + -------- + ------------ +\n| Type| length| value|\n+ ------ + -------- + ------------ +\nstruct Record {\nuint16_t type;\nuint16_t length;\nbyte [length] value;\n}}\n\nAs an example, the following is the type of 0x3c contains the 0xdeadbeef value of the record length is 4, because 0xdeadbeef is 4 bytes.\n\n**[1] [[2]](<84571_2.htm>) [[3]](<84571_3.htm>) [[4]](<84571_4.htm>) [next](<84571_2.htm>)**\n", "modified": "2017-03-23T00:00:00", "published": "2017-03-23T00:00:00", "href": "http://www.myhack58.com/Article/html/3/62/2017/84571.htm", "id": "MYHACK58:62201784571", "type": "myhack58", "title": "The Japanese version of the WPS remote code execution vulnerability detailed analysis-vulnerability warning-the black bar safety net", "cvss": {"score": 7.5, "vector": "AV:NETWORK/AC:LOW/Au:NONE/C:PARTIAL/I:PARTIAL/A:PARTIAL/"}}, {"lastseen": "2017-03-22T15:19:59", "bulletinFamily": "info", "cvelist": ["CVE-2017-2790"], "edition": 1, "description": "Word processing and work product in the vulnerability is the threat actors to exploit the useful target. Users often encounter in everyday life these software packages use the file type, and may in the email to open such a file, or be prompted to download from the website this file does not produce suspicion. \nSome of the word processing software in the use of specific language in the community is widely used, but in other places, but little known. For example, Hancom Hangul word processing tools in South Korea widely used, from JustSystems's Ichitaro Office Suite is widely used in Japan and the Japanese-Speaking communities. The use of these software and other similar word processing system of the vulnerability, an attacker can attack the target location to a specific country or its intended victim's language community. Presumably, the attacker may believe, these system attacks are likely not too will be safe the researchers found, because they may lack the exploits of the necessary software. \nRecently, Talos\u53d1\u73b02\u4e86\u4e00\u4e2a\u5229\u7528\u97e9\u6587\u5b57\u5904\u7406\u5de5\u5177\u7684\u590d\u6742\u653b\u51fbhttp://blog.talosintelligence.com/2017/02/korean-maldoc.html , which emphasizes the attacker can create a malicious file with the necessary technology, and this malicious file is designed to aim its office software Suite. \nTalos in Ichitaro Office Suite found three vulnerabilities, which software is Japanese most popular word processing program. \nThere is no indication that we are in Ichitaro Office Suite in the discovery of three vulnerabilities in any of the one already in the wild being used. However, these three kinds of vulnerability can cause an arbitrary code execution. We chose these vulnerabilities in a to explain in more detail how to exploit such a vulnerability, and by starting the calc. exe to demonstrate remote code execution meaning. \nAbout this particular vulnerability of the recommendations, please visit http://www. talosintelligence. com/reports/TALOS-2016-0197 \nIn-depth exploration of - TALOS-2016-0197\uff08CVE-2017-2790 - the JUSTSYSTEMS ICHITARO OFFICE EXCEL file code execution vulnerability\nThis vulnerability revolves around an unchecked integer underflow problem, the problem is because the Ichitaro processing XLS files to a workbook within the stream type is 0x3c when recording is not strictly check its length. \nRead in next record of type 0x3c, app calculation needs to be copied to memory in number of bytes. This calculation relates to from the file itself to read the value of subtracting a value, which led to an integer underflow. \nJCXCALC! JCXCCALC_Jsfc_ExConvert+0xa4b1e: \n44b48cda 8b461e mov eax,dword ptr [esi+1Eh] // next record of the file data\n44b48cdd 668b4802 mov cx,word ptr [eax+2] // taken from the file's record length(in our case 0) \n... \n44b48ce4 6649 dec cx // 0 underflow to 0xffff \n... \n44b48ce8 894d08 mov dword ptr [ebp+8],ecx // save the value 0xffff behind the use of\nLater in the same function, the underflow value is passed to the processing file data Copy Function. \nJCXCALC it! JCXCCALC_Jsfc_ExConvert + 0xa4b46: the \n44b48d04 0fb75508 movzx edx, word ptr [ebp + 8] //0xffff is stored into edx \n... ... \n44b48d1f 52 push edx //is pressed into the length of the\n44b48d20 51 push ecx //is pressed into the destination address\n44b48d21 83c005 add eax, 5 the \n44b48d24 52 push edx //is pressed into the length of the\n44b48d25 50 push eax //is pressed into the source address\n44b48d26 e8c5f7ffff call JCXCALC it! JCXCCALC_Jsfc_ExConvert + 0xa4334\uff0844b484f0\uff09 \nThe main copy function does have a check to make sure that the length is greater than zero. Underflow the value of fly under the radar and pass all checks. The following is a use associated variable name comment the Copy Function. Note that, since in the above-described assemblies is pressed into the same register, the following C-code in the size and size_ are equal. \nint JCXCALC! JCXCCALC_Jsfc_ExConvert+0xa4334(int src, int size, int dst, int size_) \n{ \nint result; \nresult = 0; \nif ( ! size_ ) \nreturn size; \nif ( size &gt; size_ ) \nreturn 0; \nif ( size &gt; 0 ) \n{ \nresult = size; \ndo \n{ \n*dst = *src++; \n++dst; \n\\--size; \n} \nwhile ( size ); \n} \nreturn result; \n} \nthe dst address is the address to the allocated memory, its size is also taken from the files of the TxO Record Type 0x1b6 it. This size is passed to malloc prior to the first multiplied by 2. \nJCXCALC it! JCXCCALC_Jsfc_ExConvert + 0xa4a1c: the \n442c8bd8 668b470e mov ax, word ptr [edi + 0Eh] //from a TxO the size of the element\n442c8bdc 50 push eax \n442c8bdd e88b87f6ff call JCXCALC it! JCXCCALC_Jsfc_ExConvert + 0xd1b1\uff084423136d\uff09 \nJCXCALC it! JCXCCALC_Jsfc_ExConvert + 0xd1b1: the \n4423136d 0fb7442404 movzx eax, word ptr [esp + 4] \n44231372 d1e0 shl eax, 1 in //attacker size* 2 \n44231374 50 push eax \n44231375 ff1580d42f44 call ds: malloc //controlled malloc \n4423137b 59 pop ecx \n4423137c c3 ret \nAll in all, the vulnerability to an attacker provides the following structure: \n*Memory allocation length is controlled by the value multiplied by 2 \n*memcpy into a length of 0xffff in the memory allocation, the value is from the attacker-controlled file data to obtain the\nCoverage of the target\nIf we want to on Windows 7 to exploit this vulnerability, the question now becomes, using memcpy coverage of Best goals? One approach might be to try to use virtual function overrides object's vtable, so we can use the user control's pointer to control the program counter. \nIn order to make the above become feasible, we need to use the following parameters to create: \n*The object must be to be predicted the size of the allocation to the heap area\n*The object must use a virtual function and has virtual table vtable to. \n*The object must be in coverage occurs after being destroyed. \nThe XLS file consists of a plurality of document streams, where each stream are divided into different records. Each record can be described as a type - length - value TLV\uff09structure. This means that each record will be the first few bytes specify its type, followed by the length of the record, the last is included in the recording by the length of the specified bytes of data. \n\n\n**[1] [[2]](<84549_2.htm>) [[3]](<84549_3.htm>) [[4]](<84549_4.htm>) [[5]](<84549_5.htm>) [[6]](<84549_6.htm>) [next](<84549_2.htm>)**\n", "modified": "2017-03-22T00:00:00", "published": "2017-03-22T00:00:00", "id": "MYHACK58:62201784549", "href": "http://www.myhack58.com/Article/html/3/62/2017/84549.htm", "title": "The Japanese version of the WPS remote code execution vulnerability detailed analysis-vulnerability warning-the black bar safety net", "type": "myhack58", "cvss": {"score": 7.5, "vector": "AV:NETWORK/AC:LOW/Au:NONE/C:PARTIAL/I:PARTIAL/A:PARTIAL/"}}]}