madshi.net

not Indirect Branch Tracking of CET

That's good news as it was my primary worry

Indirect branch tracking – free branch protection to defend against Jump/Call Oriented Programming

--Iconic

New build up:

http://madshi.net/madCollectionUpdate.exe

I *think* this should fix CET. But I don't currently have CET capable hardware, so I can't really verify.

Good news, but my subscription has expired.

Would you send test program to verify?

You can make the test program like this.
Create "sc.exe" process and Inject the dll which hooks NtTerminateProcess API.

I've recompiled this demo:

http://madshi.net/HookProcessTermination.zip

I have verified this issue has been fixed.

Thanks.

Thanks Jakeads,

And also thanks for pointing out that Windows only cares about RET with Intel’s CET, it’s a relief. If Windows adopted the full IBT enforcement at the hardware level both jumps and calls would also be under scrutiny. Luckily, MS likely realized that their own hotpatching/detours/DLL Shims would also refuse to function.

—Iconic

Hi

what is the schedule for including the fix for this issue in a release?

Thanks

The "hotfix" build seems to be stable. A big security company has tested it for their internal use and found no issues (so far), so I think the hotfix is probably good to go for release builds. I do plan to release an "official" new build soon(ish), but it's likely to be identical to the current hotfix, with just the documentation/version information updated. I don't really have a schedule/ETA for an official build atm, because I'm busy with another urgent project.

***Small Edit*** Die = "The" in German --Iconic

Hi, Is the hotfix applied to MCH3 too?

Sorry, but no, only v4.

MCH v4.0 is definitely worth the upgrade as there have been several fixes and additions since v3.0 which is now nearly 10 years old! Highly recommend the upgrade

--Iconic

Hi,

I think that there may still be a problem with shadow stack support. Our software is hooking PeekMessageW in chrome.exe and msedge.exe. This is causing https://bugs.chromium.org/p/chromium/is ... id=1245815

One suggested fix is:

for the shadow stack overflow would be to pop the correct number of return addresses off the shadow stack when you do the corresponding pop of the data stack. The shadow stack can be popped using the following assembly instructions:

mov ecx, 1

incsspq rcx

or this C compiler intrinsic:

void __cdecl _incsspq (unsigned __int64);

I have tried calling _incsspq(1) before returning from the PeekMessageW hook but it doesn't help. I created a test app that simply repeatedly calls PeekMessageW when it is hooked, it is terminated after a few seconds.

Thanks

Do you happen to have a crash dump or maybe you can share your code (callback only)? Does this happen with an empty callback where you just call the next hook? Lastly, and most importantly, does this happen with any other hooked APIs set in the Chrome process or is this only a PeekMessageW() issue you're experiencing?

--Iconic

In addition to iconic's good questions:

FWIW, nobody else has reported any CET issues for now. Can you reproduce the issue outside of chrome? I wonder if it's something specific to chrome which is causing this.

Also, could you please try the latest build, which has some further bugfixes (I don't recall anything CET related, though):

http://madshi.net/madCollectionUpdate.exe

Here is a stand-alone test app and dump file https://www.dropbox.com/s/34fnbg8vbx9o2 ... 3.zip?dl=0. I just took a VisualStudio app wizard, repeatedly called PeekMessage and enabled CET. As noted by Google, this manifests as a shadow stack overflow on CET supported hardware. I can replicate this situation by hooking other APIs, not just PeekMessageW.
I've just noticed that my madCodeHook subscription has expired... I'll get that renewed ASAP. I am using the version of madCollectionUpdate from this thread dated March 18.