-
Notifications
You must be signed in to change notification settings - Fork 562
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OOM with STATUS_INVALID_SYSTEM_SERVICE due to wrong NtAllocateVirtualMemory syscall # from CrowdStrike Falcon hook #7024
Comments
This was referenced Oct 7, 2024
derekbruening
added a commit
that referenced
this issue
Oct 8, 2024
Adds the use of "-vm_base 0" to mean to let the OS pick our vmcode base, with no random offset applied. This was useful during diagnosing the OOM from the CrowdStrike hook. Issue: #7024
This was referenced Oct 8, 2024
derekbruening
added a commit
that referenced
this issue
Oct 9, 2024
Replaces the AUTOMATED_TESTING set in package builds by PR #5769 with a new DISABLE_ZLIB CMake option to accomplish the goal of disabling the zlib found on these VMs while avoiding turning off msgbox_mask. The disabling by default of msgbox_mask in packages has caused many users to fail to obtain error information and has led to confusion with silent errors. Tested: built a cronbuild based on this branch and downloaded it to the Windows VM used for #7024. I ran this: ``` C:\Users\bruening\DynamoRIO-Windows-10.93.20004>bin64\drrun -- msg <Application C:\Windows\system32\msg.exe (3892). Out of memory. Program aborted. Source I, type 0x0000000000000001, code 0x00000000c000001c.> ``` And confirmed a messagebox popped up: thus showing that `-msgbox_mask` is *not* set to 0 anymore. Issue: #7025
derekbruening
added a commit
to DynamoRIO/drmemory
that referenced
this issue
Oct 9, 2024
Updates DR to [a15656a0c](36a6d23). Replaces the AUTOMATED_TESTING set in package builds by PR #2474 with the new DISABLE_ZLIB CMake option added by DynamoRIO/dynamorio#7030. This fixes a regression where msgbox_mask was set to 0 by default in packages, which caused many users to fail to obtain error information and has led to confusion with silent errors. Tested: Built https://github.com/DynamoRIO/drmemory/releases/tag/cronbuild-2.6.20005, unzipped it, and confirmed it pops up a message box by default on the machine where DynamoRIO/dynamorio#7024 is hit. Fixes DynamoRIO/dynamorio#7025
derekbruening
added a commit
that referenced
this issue
Oct 9, 2024
Adds the use of "-vm_base 0" to mean to let the OS pick our vmcode base, with no random offset applied. This was useful during diagnosing the OOM from the CrowdStrike hook. Issue: #7024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
A number of users of Dr. Memory have complained about startup failures on Windows Enterprise. Since Dr. Memory prints a list of libraries it sees in its launcher that are not on an (old-ish) known library list as possible interoperability causes (since security software often fails to work well with low-level tools like ours), Dr. Memory was printing out that "bcrypt.dll" might be the culprit and so many users put that in the issue titles or used that to refer to the problem.
E.g.: https://groups.google.com/g/drmemory-users/c/9wM120ukp6c
I managed to reproduce this and the external symptoms are like this:
Debug build hits this assert on failing to allocate:
The failure code is usually this one:
Though I have seen it vary: I've seen 0x80000002, 0xc0000005, and others.
This seems to be the same as DynamoRIO/drmemory#2447.
On looking deeper we see:
The problem is that DR gets the wrong system call number for NtAllocateVirtualMemory:
The number should be 0x18:
There's a hook in there clobbering the number:
DR tries to detect a hook during number acquisition but it only looks at the entry pc: so this deeper hook is not caught there.
I don't have a debugger in my test machine: but I do see that DrMemory complains about
c:\windows\system32\umppc18613.dll
in addition to bcrypt.dll. Andumppc18613.dll
isCrowdStrike Falcon Sensor Support Module
which is almost certainly the culprit doing this hooking.Action items:
For that last one this comment in the code lists the options:
If we had detected the hook, we would have fallen back to the
windows_10_1803_x64_syscalls
numbers: which do have NtAllocateVirtualMemory correct but may have others wrong.Trying to make the options more concise here for the numbers:
The text was updated successfully, but these errors were encountered: