search

DynamoRIO / dynamorio

Dynamic Instrumentation Tool Platform
Other
2.65k stars 560 forks source link

when built with VS2013 you can't catch an x64 fault on jumping to an invalid address? #1423

Open derekbruening opened 9 years ago

derekbruening commented 9 years ago

From bruen...@google.com on April 10, 2014 15:06:45

When built with VS2013, x64 security-common.retnonexisting fails. It fails natively as well:

% suite/tests/bin/security-common.retnonexisting.exe starting good function in foo first foo a=1 in foo second foo a=2 starting bad function looking at ring 0x0000000000000001 Segmentation fault

Can't seem to catch the fault. I can catch a write fault -- just not this jmp-to-0x1 fault. Local __try doesn't do it either. Debugger is no help as usual with exception handling problems.

We seem to be linking with "/safeseh:no" but removing it makes no difference. A simple build from cmdline doesn't fix it: % cd ~/dr/build_suite/build_debug-internal-64/suite/tests % cl /Zi /Febin/security-common.retnonexisting.exe ../../../../git/src/suite/tests/security-common/retnonexisting.c /I../../../../git/src/suite/tests /I../.. bin/tools.lib

Doing the same thing after "compilerVS2012_64" => the test works fine.

Why is this limited to VS2013?

Under DR, DR forges the exception, but the app doesn't even catch that. The SEH code in ntdll goes and does a fatal NtRaiseException. This happens even if I change the forged pc to be a real valid pc! : looking at ring 0x0000000000000001 <Application tried to execute from unreadable memory 0x0000000000000001. This may be a result of an unsuccessful attack or a potential application vulnerability.> Segmentation fault

I'm stumped. I thought that even if there's no entry in the SEH64 table (perhaps explaining the failure of __try to work), you could still catch faults at the top level. And given that this works when built with VS2012 -- what's going on?

Original issue: http://code.google.com/p/dynamorio/issues/detail?id=1423

derekbruening commented 9 years ago

From bruen...@google.com on April 10, 2014 13:30:00

Labels: GoodContrib Component-Tests

derekbruening commented 9 years ago

From bruen...@google.com on April 13, 2014 11:44:04

It looks like release build catches the exception: so it's only debug that doesn't

derekbruening commented 9 years ago

From bruen...@google.com on April 15, 2014 14:45:50

*\ TODO VS2012-built app on win8 x64 hitting a similar problem but only on NULL address?

This test on x64 win8 fails: http://build.chromium.org/p/client.dynamorio/builders/win-8-dr/builds/526/steps/pre-commit%20suite/logs/stdio I can reproduce locally. Natively it dies but further in than the VS2013 case:

% suite/tests/bin/security-common.retnonexisting.exe starting good function in foo first foo a=1 in foo second foo a=2 starting bad function looking at ring 0x0000000000000001 fault caught on 0x0000000000000001 looking at ring 0x0000000000000000 Segmentation fault

On both the win8 bot and my local machine, VS2012 is being used to build it.

derekbruening commented 9 years ago

From bruen...@google.com on April 15, 2014 15:15:27

turns out we already have issue #962 for the win8 failure. needs confirming but they are likely related