{"id":98785,"date":"2018-05-18T07:00:00","date_gmt":"2018-05-18T21:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/?p=98785"},"modified":"2019-03-13T00:44:07","modified_gmt":"2019-03-13T07:44:07","slug":"20180518-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20180518-00\/?p=98785","title":{"rendered":"Misdirected security vulnerability: Malformed file results in memory corruption"},"content":{"rendered":"

A security vulnerability report arrived that went something like this: <\/p>\n

\n

Subject<\/b>: An Exploitable Vunerability in dwrite.dll (stack hash 0x6b6f6f4c.0x4654d7441) <\/p>\n

The file dwrite.dll<\/code> allows an attacker to execute arbitrary code or trigger a denial of service by a crafted corrupted PNG file. This vulnerability can be reproduced by using LitWare<\/a> Publisher 2.0, clicking Insert Image<\/i> and then selecting the attached PNG file. Debugger output follows: <\/p>\n

\nModLoad: 00060000 0009f000   litware.exe\nModLoad: 77df0000 77f47000   ntdll.dll\nModLoad: 76dd0000 76ea0000   C:\\WINDOWS\\SysWOW64\\KERNEL32.DLL\n...\nModLoad: 71e40000 71e59000   C:\\Windows\\SysWOW64\\dwrite.dll\n\n(1788.17ec): Access violation - code c0000005 (first chance)\neax=00000000 ebx=0039d82c ecx=0000000a edx=00000000 esi=006c6608 edi=36363636\neip=767b997e esp=003afb44 ebp=003afb54 iopl=0 nv up ei pl zr na pe nc\ncs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246\nmsvcrt!_VEC_memzero+0x6a:\n767b997e f3aa rep stos byte ptr es:[edi]\n\n0:004> k\nChildEBP RetAddr\n003afb54 74db8b92 msvcrt!_VEC_memzero+0x6a\n003afb8c 68f41cbf COMCTL32!Progress_Paint+0x4c\n003afba8 68ff6fbb COMCTL32!Progress_UpdatePosition+0x6b\n003afbbc 690c3dea COMCTL32!Progress_Update+0x46\n003afc48 756377d8 COMCTL32!Progress_WndProc+0x14bfdc\n003afc74 756378cb USER32!InternalCallWinProc+0x23\n003afcf0 7563f139 USER32!UserCallWinProcCheckWow+0x100\n003afd58 75648fce USER32!SendMessageWorker+0x656\n003afd80 0006e7db USER32!SendMessageA+0x8b\n003afdbc 00080688 litware+0xe7db\n003afde0 00092061 litware+0x20688\n003affa8 0007ff75 litware+0x32061\n003affc4 0008fe12 litware+0x1ff75\n003b00ec 00074066 litware+0x2fe12\n003b1760 756377d8 litware+0x14066\n003b2d40 756378cb USER32!InternalCallWinProc+0x23\n003b2d6c 7563f139 USER32!UserCallWinProcCheckWow+0x100\n003b2de8 75648fce USER32!SendMessageWorker+0x656\n003b2e50 00e949db USER32!SendMessageA+0x8b\n003b2e78 00e9546f litware+0x1849db\n003b2ec8 0108a800 litware+0x18546f\n003b307c 77a7850d litware+0x37a800\n003b30c8 77e4bf39 KERNEL32!BaseThreadInitThunk+0xe\n003b30d4 77e4bf0c ntdll!__RtlUserThreadStart+0x72\n003b3118 00000000 ntdll!_RtlUserThreadStart+0x1b\n\n0:004> !exploitable\n\nExploitability Classification: EXPLOITABLE\nRecommended Bug Title: Exploitable - User Mode Write AV\n    starting at msvcrt!_VEC_memzero+0x000000000000006a\n    (stack hash 0x6b6f6f4c.0x4654d7441)\n\nUser mode write access violations that are not near NULL are exploitable.\n<\/pre>\n<\/blockquote>\n
Okay, let’s look at what we were given. We have a stack trace, where the code is trying to zero out a block of memory, but the address of that block of memory is 0x36363636<\/code>, which is invalid and awfully suspicious. This was classified by the !exploitable<\/code> debugger extension<\/a> as exploitable because the bad address is used control a write. <\/p>\n
Great, now let’s look at the analysis by the submitter. <\/p>\n
The submitter says that the vulnerability is in dwrite.dll<\/code>. It’s not clear from the stack trace why dwrite.dll<\/code> is getting the blame. After all, there is no dwrite<\/code> code anywhere on the stack. <\/p>\n
The only appearance of dwrite<\/code> in the debugger output is the fact that dwrite.dll<\/code> was the DLL most recently loaded by the process. I guess the submitter decided that this was enough to pin the blame on dwrite.dll<\/code>. “The most recent person to enter the room is responsible for everything bad that happens.” <\/p>\n
(Note that they quite pointedly took the bug title that the !exploitable<\/code> debugger extension recommended and changed the name of the DLL, while keeping the rest the same, including the stack hash!) <\/p>\n
What more likely happened is that loading the malformed PNG file caused LitWare to corrupt some memory that Progress_Paint<\/code> was using, and then when LitWare finally got around to updating the progress control, the Progress_Paint<\/code> function crashed because its pointer to some internal data structure got corrupted. <\/p>\n
This is a case of somebody knowing just enough to be dangerous. They found the !exploitable<\/code> debugger extension, but they didn’t understand how to use it. <\/p>\n
Yes, they found a vulnerability. But they didn’t understand how to assign the blame, so they blamed Microsoft! <\/p>\n
This issue needs to go to the publishers of LitWare. Their program is the one that is corrupting memory in response to the malformed PNG file. <\/p>\n
Bonus chatter<\/b>: This conclusion took some time to verify, because it’s possible that LitWare Publisher uses a component provided by Microsoft (such as the Windows Imaging Component<\/a>) to decode PNG files, in which case the vulnerability could be in that component rather than in LitWare itself. But we were able to confirm that the memory corruption was coming from LitWare’s own custom PNG decoder. <\/p>\n
This last step is important, because if you had simply redirected the report without investigating it, and the problem really was in, say, the Windows Imaging Component, then  you are in the unenviable position of having been informed of a security vulnerability and blown it off. And then when the vulnerability makes the front page of the news, everybody’s going to say, “What a bunch of idiots over there at Microsoft. They received the vulnerability report months ago and rejected it as not their bug!” <\/p>\n
Bonus chatter<\/b>: Turns out that the finder was using an old version of LitWare. The problem doesn’t exist in the latest version of LitWare, so presumbly LitWare already found and fixed the problem on their side. <\/p>\n","protected":false},"excerpt":{"rendered":"
Who did the corrupting?<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[26],"class_list":["post-98785","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-other"],"acf":[],"blog_post_summary":"
Who did the corrupting?<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/98785","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=98785"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/98785\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=98785"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=98785"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=98785"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}