Remove syscall hook from BlueKeep payload #12553
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Release NotesSyscall hooking has been removed from the BlueKeep exploit, adapting it for targets with the Meltdown patch installed. |
msjenkins-r7
pushed a commit
that referenced
this pull request
Nov 11, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This removes all syscall hooking code from BK payload. Syscall hooking is only needed to lower DISPATCH_LEVEL, however sleepya pointed out BK
call [rax]gadget happens at PASSIVE_LEVEL. This avoids needing to bypass Meltdown KVA shadow as well. Overall reliability in the wild improves immensely as targets WITH Meltdown patch are a common scenario.Note when testing there are pre-existing bugchecks 0xa and 0x3b because the resource lock at
fake_channel+0x18is part of the allocation header (not directly under our control like the call gadget). It may be possible to have that code path attacker controlled but it will require some digging. For another time...Edit: The Meltdown announcement was in Jan2018, but I'm not sure exactly when Meltdown fix code was put in place. Looks like possibly Nov 2017ish. Certainly after Jan2018, I tested 2010 and 2019 kernel.
Verification
msfconsoleuse cve_2019_0708_bluekeep_rce