{"id":102316,"date":"2019-03-15T07:00:00","date_gmt":"2019-03-15T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=102316"},"modified":"2019-06-06T17:34:46","modified_gmt":"2019-06-07T00:34:46","slug":"20190315-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20190315-00\/?p=102316","title":{"rendered":"How can we use IsBadWritePtr to fix a buffer overflow, if IsBadWritePtr is itself bad?"},"content":{"rendered":"

A customer asked for assistance in investigating an access violation caused by a buffer overflow. They figured that they could probe whether the buffer is large enough to receive the data by using Is­Bad­Write­Ptr<\/code>, but then they saw that Is­Bad­Xxx­Ptr<\/code> should really be called Crash­Program­Randomly<\/code><\/a>. They were wondering what alternatives existed to Is­Bad­Xxx­Ptr<\/code>. <\/p>\n

The alternative to Is­Bad­Xxx­Ptr<\/code> is not passing bad pointers in the first place<\/i>. <\/p>\n

If you are getting an access violation from a buffer overflow, the fix for the problem is not to try to detect the overflow as it happens. the fix is to stop the overflow before<\/i> it happens. <\/p>\n

The customer shared their code and the stack trace at which the access violation occurred: <\/p>\n

\nmsvcrt!memcpy+0xb4\ncontoso!CBuffer::CopyFromRange+0x92\ncontoso!CBuffer::ReadAt+0x861\ncontoso!CLockBytes::ReadAt+0xfd\ncontoso!CStream::Read+0xe3\ncontoso!CData::ParseFile+0x606\n<\/pre>\n
The buffer overflow occurred because the memcpy<\/code> was writing past the end of the buffer passed to CStream::Read<\/code>. The thing to do is not try to detect the maximum writable buffer size, but to stop passing invalid buffer sizes. <\/p>\n
Because there’s probably writable memory after the buffer that is not part of the buffer. If the invalid buffer size were only slightly larger than the buffer (rather than ridiculously larger than the buffer), you wouldn’t have gotten an access violation, but you still had a buffer overflow. <\/p>\n
The offending Read<\/code> call came from here: <\/p>\n
\n\/\/ Code in italics is wrong\n    uint32_t numBlocks;\n    uint32_t actualBytesRead;\n\n    \/\/ First, read the number of blocks.\n    HRESULT hr = stream.Read(&numBlocks, sizeof(uint32_t), &actualBytesRead);\n    if (FAILED(hr) || actualBytesRead != sizeof(uint32_t)) {\n        goto Reject;\n    }\n\n    \/\/ Next, read the size of each block.\n    uint32_t blockSize;\n    hr = stream.Read(&blockSize, sizeof(uint32_t), &actualBytesRead);\n    if (FAILED(hr) || actualBytesRead != sizeof(uint32_t)) {\n        goto Reject;\n    }\n\n    \/\/ Now read the blocks.\n    DWORD i;\n    for (i = 0; i < numBlocks; i++)\n    {\n        \/\/ Read each block.\n        BLOCK block = { 0 };\n        hr = stream.Read(&block, blockSize, &actualBytesRead);<\/i>\n        \/\/               ^^^^^^^^^^^^^^^^^ invalid buffer here\n        if (FAILED(hr) || actualBytesRead != sizeof(uint32_t)) {\n            goto Reject;\n        }\n<\/pre>\n
The stack trace implicates the highlighted line of code. <\/p>\n
So how do we prevent the invalid buffer from being passed to the Read<\/code> method? <\/p>\n
From code inspection, we see that we read blockSize<\/code> bytes into a BLOCK<\/code> structure, but we didn’t take any steps to ensure that blockSize<\/code> is no larger than at BLOCK<\/code>. In other words, we have a buffer of size sizeof(BLOCK)<\/code>, and we ask to read blockSize<\/code> bytes into it, so it is our responsibility to ensure that blockSize <= sizeof(BLOCK)<\/code>. <\/p>\n
However, no such buffer size validation was present. <\/p>\n
How to fix this depends on how you want to deal with unexpected block sizes. <\/p>\n
If your intent is to allow large block sizes and just ignore the fields that are “from the future”, then you would read min(blockSize, sizeof(block))<\/code> bytes, and then Seek<\/code> over the extra bytes (if any). <\/p>\n
If your intent is to reject large block sizes, then go ahead and reject them. <\/p>\n","protected":false},"excerpt":{"rendered":"
Don’t catch the overflow as it happens. Stop the overflow before it happens.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-102316","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Don’t catch the overflow as it happens. Stop the overflow before it happens.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/102316","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=102316"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/102316\/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=102316"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=102316"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=102316"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}