Don’t trust the return address

Date:January 1, 2004 / year-entry #1
Tags:code
Orig Link:https://blogs.msdn.microsoft.com/oldnewthing/20040101-00/?p=41223
Comments:    17
Summary:Sometimes people ask, "So I know how to get my return address [use the _ReturnAddress() intrinsic]; how do I figure out what DLL that return address belongs to?" Beware. Even if you figure out which DLL the return address belongs to [use Get­Module­Handle­Ex(GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS)], that doesn't mean that that is actually the DLL that called you....

Sometimes people ask, "So I know how to get my return address [use the _ReturnAddress() intrinsic]; how do I figure out what DLL that return address belongs to?"

Beware.

Even if you figure out which DLL the return address belongs to [use Get­Module­Handle­Ex(GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS)], that doesn't mean that that is actually the DLL that called you.

A common trick is to search through a "trusted" DLL for some code bytes that coincidentally match ones you (the attacker) want to execute. This can be something as simple as a "retd" instruction, which are quite abundant. The attacker then builds a stack frame that looks like this, for, say, a function that takes two parameters. 

trusted_retd
hacked parameter 1
hacked parameter 2
hacker_code_addr

After building this stack frame, the attacker then jumps to the start of the function being attacked.

The function being attacked looks at the return address and sees trusted_retd, which resides in a trusted DLL. It then foolishly trusts the caller and allows some unsafe operation to occur, using hacked parameters 1 and 2. The function being attacked then does a "retd 8" to return and clean the parameters. This transfers control to the trusted_retd, which performs a simple retd, which now gives control to the hacker_code_addr, and the hacker can use the result to continue his nefarious work.

This is why you should be concerned if somebody says, "This code verifies that its caller is trusted..." How do they know who the caller really is?

Comments (17)
  1. ep says:
    January 1, 2004 at 8:42 am

    So is there a way to verify that my caller is trusted and allows some operations?

  2. zz says:
    January 1, 2004 at 9:56 am

    Raymond, see this yet?

    http://www.latext.com/pm/comments/P134_0_1_0/

  3. Peter Torr says:
    January 1, 2004 at 12:02 pm

    Well, in .NET you have IPermission.Demand() to see if all your callers have the right permissions, or SecurityAction.LinkDemand if you just want to check your immediate caller (which is generally a really bad idea — avoid using LinkDemands to enforce security; they’re better suited to improving API usability).

  4. Phaeron says:
    January 1, 2004 at 2:40 pm

    There are other reasons why the return address shouldn’t be used to determine the caller: the source may be a dynamically generated code fragment, and the call to the DLL function may be a tail call (jmp dword ptr [__imp__DefWindowProc@16]).

    Incidentally, what is the "sanctioned" method of emulating GetModuleHandleEx(GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS) on pre-XP platforms? The only way I know of is to VirtualQuery() the address and case the AllocationBase to HMODULE.

  5. Raymond Chen says:
    January 1, 2004 at 3:16 pm

    zz: It looks like they focused on my phrase "You dummy". I didn’t mean it to be as insulting to the user as it turned out. I should have written "Psst" instead, but what’s done is done.

  6. Steve Sheppard says:
    January 1, 2004 at 8:02 pm

    No, you did the right thing. You wrote what you meant, they CHOSE to be insulted by it. Don’t play the PC game by trying to guess what they will insulted by because the answer is eveything. Anyone who reads your blog regularly knows what you mean and to hell with idiots like that guy.

    Keep up the good work!

  7. Peter Lund/firefly@diku.dk says:
    January 3, 2004 at 1:54 am

    why would anyone try to get the return address?

  8. Raymond Chen says:
    January 3, 2004 at 8:49 am

    Because they want to do things "only if their caller is trusted".

  9. Peter Lund/firefly@diku.dk says:
    January 3, 2004 at 9:30 am

    But, but… that *really* makes no sense :)

    Reminds me of the Poly/Turbo/Borland Pascal programmers I’ve met who wanted an "exit2" pseudo procedure that would leave not just one but /two/ procedures.

    (exit is like return in C without an argument, Pascal can have nested functions unlike C (but like gcc))

    I thought at least *somebody* had had a real need for it?

  10. The Millionth Monkey Speaks says:
    January 12, 2004 at 11:16 am

    Recently on Raymond Chens blog he had a post about not trusting return addresses. Specifically to not use the _ReturnAddress() intrinsic and GetModuleHandleEx to figure out if the caller is trusted. I had to try and come up with a…

  11. Robert Horvick's Weblog says:
    January 15, 2004 at 11:40 am
  12. Robert Horvick's Weblog says:
    January 15, 2004 at 11:41 am
  13. The Old New Thing says:
    March 20, 2004 at 9:18 am
  14. The Old New Thing says:
    May 23, 2005 at 9:00 am

    Because there sometimes isn’t enough information to determine what the "right" order is.

  15. The Old New Thing says:
    July 20, 2005 at 10:00 am

    Counterintuitive results from the file search.

  16. The Old New Thing says:
    February 3, 2006 at 10:00 am

    Thanks to code injection.

  17. The Old New Thing says:
    August 17, 2006 at 10:00 am

    No really, you can’t.

Comments are closed.


*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index