Beware the Image File Execution Options key

Date:December 19, 2005 / year-entry #390
Tags:other
Orig Link:https://blogs.msdn.microsoft.com/oldnewthing/20051219-11/?p=32923
Comments:    20
Summary:Beware the Image File Execution Options key (more). Its power can be used for evil as well as for good. Its intended use is to force a program to run under a debugger regardless of how it is launched (and secondarily to alter how the system treats the program). It's handy if you need to...

Beware the Image File Execution Options key (more). Its power can be used for evil as well as for good.

Its intended use is to force a program to run under a debugger regardless of how it is launched (and secondarily to alter how the system treats the program). It's handy if you need to debug a program "in the wild" rather than under the controlled environment of your favorite IDE. For example, you can use it if you want to debug how a program runs when it is launched by some other program you can't debug.

Two things people often forget:

  • If you err in specifying the debugger, the program won't launch at all. For example, if you get the path to the debugger wrong or if you subsequently uninstall the debugger, you'll get ERROR_FILE_NOT_FOUND when you try to run the target program since the system can't find the debugger.
  • Remember to delete the entry for your program when you no longer need it. Otherwise you'll wonder why the debugger keeps launching for no apparent reason.

Evil can be done with the Image File Execution Options key. Malware can install themselves as the "debugger" for a frequently-run program (such as Explorer) and thereby inject themselves into the execution sequence.

Note that the ability to use the Image File Execution Options key for evil purposes is not a security hole. To modify the key in the first place requires administrator permissions. Consequently, anybody who can exploit this feature already owns your machine.


Comments (20)
  1. GregM says:

    Thank you!!!!

    I wish I knew about this YEARS ago. It’s always a pain to try to debug startup problems that only happen when a user double-clicks on one of your files in Windows Explorer.

  2. One non-debugging use (for good): Process Explorer (from SysInternals.com) can make itself a replacement for Task Manager. The IFEO key is how it does that.

    The fact that it can be used for Evil is why IFEO keys are listed by SysInternals’ "AutoRuns" utility. But as Raymond alludes, if the bad guys have inserted an IFEO key, they can also load a kernel-mode rootkit that can completely hide the fact that they’ve done so.

  3. Cheong says:

    Dan McKinley,

    Your comment make me think of the idea for commercial spys to steal information.

    In a less secure company where staffs share workstations and everyone has admin right login, one can easily use prewritten programs to inject the key to other users registry, then have others run the background program to steal information using their identity.

    The spy will just have to remember to wipe the key out when completed, and the database log will only show the ID of another staff have downloaded suspiciously huge amount of data.

    How do others think? I’ll be glad to know this won’t be the case for whatever reason.

  4. Dan McKinley says:

    I think that’s basically what Raymond is saying. I gave a fairly benign abuse of the debugger value, but running users as admins opens you up to malware that takes advantage of it.

  5. Norman Diamond says:

    If you insert a Sony CD into your machine while logged in with administrative privileges, then Sony 0wns your machine. So why did Sony bother constructing a rootkit? They 0wn your machine.

    Well, Sony constructed a rootkit because they wanted to make it difficult for you to discover that they 0wn your machine. Malware does benefit by making it hard for you to notice it’s there.

    Of course we can’t do away with such an important debugging tool, but maybe something can be done. Consider that blank passwords, even when they are the correct passwords, no longer authenticate incoming network connections. Maybe the Image File Execution Options key can be made more restrictive, maybe only allowing the launching of known debuggers so that the user knows it’s happening.

  6. Aaron says:

    You don’t think thats a security hole? How many people run the different versions of Windows out there as a non-admin?

    I’ve never run as anything other than an Admin. Windows just doesn’t seem designed for you to switch users or something when you want to do an Admin task… Maybe thats just cause I have used it for awhile, but I gotta figure there are tons of people like me out there.

  7. Dean Harding says:

    But that’s the point, Aaron, if you’re already running as an admin then there’s nothing that these keys will give you that you can’t do already. It’s only a security problem if they gave you MORE power than you would normally have. For example, if you were already an admin there’s no reason why you couldn’t just copy your malicious executable over C:WINDOWSnotepad.exe.

    The security hole is the fact that you’re running as an admin in the first place, not the fact that an admin can modify those keys.

  8. Tim Marman says:

    Yeah, I wrote about using this for comedy back in 2004 in a post entitled "How to Have Fun… At the expense of your coworkers".

    http://slashstar.com/blogs/tim/archive/2004/07/12/751.aspx

  9. Norman, what is a "known debugger" ?

    There is a whole bunch of debuggers from different vendors, open source or in house developed.

    The power of choosing which ones are trusted debuggers and which ones aren’t won’t choose the fair competition price..

  10. Typo : "won’t *choose* the fair competition price" is "won’t *win* the fair competition price" ;)

  11. Norman Diamond says:

    Wednesday, December 21, 2005 4:17 AM by Purplet [italy]

    > Norman, what is a "known debugger" ?

    I meant one that’s known to the currently running system, e.g. if the administrator has installed Visual Studio 6 and Visual Studio 2005 beta 1 and WinDbg then probably 3 debuggers have been registered.

  12. Mike Fried says:

    Norman Diamond wrote: "I meant one that’s known to the currently running system, e.g. if the administrator has installed Visual Studio 6 and Visual Studio 2005 beta 1 and WinDbg then probably 3 debuggers have been registered."

    So that just requires an extra step of registering a debugger so you can set it on .exe files. It’s an extra hoop that doesn’t make a significant difference in the complexity of the attack, and most users don’t know what a debugger is, and never launch one intentionally.

    I’m going to repeat the mantra: Once someone gets root on your PC the game is over. They own your system. The barriers you throw up only complicate the computer for the technical user. The average user isn’t skilled enough to know the difference between a debugger and an anti-virus. They just don’t care. Your added check wouldn’t prevent the hackers from having their way with your system once you gave them root.

  13. Anon says:

    Unfortunately there is a lot of software out there that assumes it is running in admin mode, and doesn’t work properly otherwise. Including some MS stuff. This forces users to run in admin mode. There needs to be an education effort with both developers and users that this behaviour is a very very bad thing.

  14. Be careful  of Image File Execution Options (IFEO) with managed debugging – it won’t work like you…

  15. You’ve already lost the game.

  16. Every now and than while debugging I need to either determine when a dll/module is loaded or need to

  17. Wes' Blog says:

    Every now and than while debugging I need to either determine when a dll/module is loaded or need to

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