{"id":108505,"date":"2023-07-31T07:00:00","date_gmt":"2023-07-31T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=108505"},"modified":"2023-07-31T07:28:25","modified_gmt":"2023-07-31T14:28:25","slug":"20230731-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20230731-00\/?p=108505","title":{"rendered":"Misinterpreting the misleadingly-named STATUS_STACK_BUFFER_OVERRUN<\/CODE>"},"content":{"rendered":"

I noted some time ago that STATUS_STACK_BUFFER_OVERRUN<\/code> doesn’t mean that there was a stack buffer overrun<\/a>, although that’s what it meant at first. Later, the status code was broadened to mean “Program self-triggered abnormal termination”, but it was too late to change the name.<\/p>\n

A security vulnerability report came in that went like this:<\/p>\n

\n

I have found a stack overflow bug in Explorer. This stack overflow occurs in ucrtbase.dll and Windows.UI.FileExplorer.dll. Since it occurs in Explorer, this can be exploited to escalate privileges. To reproduce, download the attached ZIP file and right-click it. I have also attached Explorer crash dumps for analysis.<\/p>\n

EXCEPTION_RECORD: (.exr -1)\r\nExceptionAddress: 00007ffcaa19dd7e (ucrtbase!abort+0x000000000000004e)\r\nExceptionCode: c0000409 (Security check failure or stack buffer overrun)\r\nExceptionFlags: 00000001\r\nNumberParameters: 1\r\nParameter[0]: 0000000000000007\r\nSubcode: 0x7 FAST_FAIL_FATAL_APP_EXIT\r\n\r\nSTACK_TEXT:\r\nucrtbase!abort+0x4e\r\nucrtbase!terminate+0x29\r\nucrtbase!__crt_state_management::wrapped_invoke<void (__cdecl*)(void) noexcept,void>+0xf\r\nexplorer!_scrt_unhandled_exception_filter+0x5a\r\nKERNELBASE!UnhandledExceptionFilter+0x1f1\r\nntdll!LdrpLogFatalUserCallbackException+0xa2\r\nntdll!KiUserCallbackDispatcherHandler+0x20\r\nntdll!RtlpExecuteHandlerForException+0xf\r\nntdll!RtlDispatchException+0x25a\r\nntdll!RtlRaiseException+0x163\r\nKERNELBASE!RaiseException+0x6c\r\nmsvcr90!_CxxThrowException+0x86\r\ncontoso+0x104d\r\ncontososhellext!OnInvokeCommand+0x548\r\ncontososhellext!OnInvokeCommand+0x24d2a\r\ncontososhellext!OnGetCommandString+0x4f\r\ncontoso+0x2abd\r\ncontoso+0x27f0\r\nshell32!CDefFolderMenu::GetCommandString+0x1f6\r\nshell32!CDefFolderMenu::_UnduplicateVerbs+0x31f\r\nshell32!CDefFolderMenu::QueryContextMenu+0x7d2\r\nshell32!CDefView::_DoContextMenuPopup+0x2f7\r\nshell32!CDefView::OnSelectionContextMenu+0x85\r\nexplorerframe!UIItemsView::ShowContextMenu+0x378\r\nexplorerframe!CItemsView::ShowContextMenu+0x17\r\nshell32!CDefView::_DoContextMenu+0x92\r\nshell32!CDefView::_OnContextMenu+0xec\r\nshell32!CDefView::WndProc+0x718\r\nshell32!CDefView::s_WndProc+0x5c\r\nuser32!UserCallWinProcCheckWow+0x33c\r\nuser32!CallWindowProcW+0x8e\r\n<\/pre>\n<\/blockquote>\n
From the exception record, we see that this was a fast-fail: FAST_FAIL_FATAL_APP_EXIT<\/code>.<\/p>\n
From the stack trace we can see that this was due to an unhandled C++ exception thrown by Contoso: Contoso called _CxxThrowException<\/code>, and this ended up reaching the _scrt_unhandled_exception_filter<\/code>, which decided to terminate<\/code> the process.<\/p>\n
The problem is therefore with the Contoso shell extension: When you right-click this file, the Contoso shell extension throws a C++ exception which it does not handle.<\/p>\n
C++ exceptions cannot be thrown across the ABI boundary because there’s no requirement in the ABI that the calling code even be written in C++ at all!\u00b9 And certainly unhandled C++ exceptions are really bad ideas.<\/p>\n
There is a bug here, but the bug is in the Contoso shell extension, not in Explorer. Such is the punishment for allowing third party extensibility: Any bug in a third party extension manifests itself as a bug in Explorer.<\/p>\n
\u00b9 For example, the Windows 95 shell was written in C.<\/p>\n","protected":false},"excerpt":{"rendered":"
The subcode tells you why we stopped executing, and it’s rarely because of a stack buffer overflow.<\/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":[25],"class_list":["post-108505","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
The subcode tells you why we stopped executing, and it’s rarely because of a stack buffer overflow.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/108505","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=108505"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/108505\/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=108505"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=108505"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=108505"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}