2

I am auditing (reverse engineering) an x86 C++ application without source code. Static analysis revealed that the application is using the IsBadReadPtr and IsBadWritePtr Win32 functions in almost ALL cases, to check the function parameters. So, these two functions are called from almost all of the functions found in the application.

I've came across the following posts, saying that IsBadXXXPtr functions should not be used. I was unable to understand the security risk of using the above mentioned functions, can anybody explain it to me?

  • Not really an MS programmer so don't want to give a full answer, but from looking at the doc, it seems these functions can introduce unpredictable behavior in your app. This includes your app randomly crashing. Whether these problems will occur is impossible to answer without lots more analysis of the code. – Neil Smithline Feb 16 '16 at 0:57
2

TL;DR

The reason why they're bad is listed in the links you've provided. Due to how the Windows OS is designed, the way the functions were coded, and the fact that determining if memory is valid is hard makes these functions inherently unstable to use.


There is no good way to determine if a pointer is using a valid part of memory. Freed memory doesn't necessarily get zeroed out or reset. If there is a bad pointer floating around it could point to data that in a valid portion of memory. Just because you can dereference the pointer doesn't mean that the data itself is valid.

Those two functions use page guard exceptions to determine if the memory is valid. The design of these exceptions is not supposed to be used as a "valid memory address" check. As described by the first link:

The IsBadXxxPtr function will catch the exception and return “not a valid pointer”. But guard page exceptions are raised only once. You just blew your one chance. When the code that is managing the guard page accesses the memory for what it thinks is the first time (but is really the second), it won’t get the guard page exception but will instead get a normal access violation

Basically even by using these functions you can cause access violations because of the overall design of the Windows OS, and how these functions were coded. Even if you're not using page guards there's no guarantee that other shared libraries that you're loading aren't using page guards.

Trying to catch exceptions from the OS that are trying to tell you that things have gone terribly wrong is a bad idea. There is a programming error somewhere and the best option is to crash. Trying to return to a good state when things go that wrong can cause undetermined behavior.

The bottom line is you can't fix what went wrong with memory. Continuing execution will only burn you later.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.