It rather involved being on the other side of this airtight hatchway: Executable corruption


In the category of dubious vulnerability, I submit the following (paraphrased) report:

I discovered that if I take an EXE file and corrupt its header, then when I try to run the EXE file, the process starts up and then crashes. I used the information in the crash dialog to direct further investigations, noting that the specific crash location could be controlled by modifying particular bytes in the EXE. Finally, I was able to put all the details together to form an exploit: I modified a block of bytes in the EXE file to consist of code which opens a network socket and connects it to a command shell, then modified the header to point to those bytes. When I run the EXE, the exploit code runs, and I can connect to the network socket from another computer and control the command shell.

Yeah, that's great, but what's the vulnerability? What you did was take a program that you have write permission to and change the code in it to run your exploit. If you can modify an EXE file, then you may as well just replace the entire contents of the file with the bytes of PWNZ0RD.EXE. In other words, modifying bytes here and there is just a very slow, inefficient, and unnecessarily complicated way of doing this:

copy pwnz0rd.exe victim.exe

Then when the user runs the infected program, they're really running the PWNZ0RD.EXE program, and your so-called exploit can do whatever it wants. That's a lot easier than trying to modify a dozen bytes here, a dozen bytes there.

In order to trigger the vulnerability, the user has to run the compromised program, but a program is already arbitrary code. No need to be so sneaky about it. It's sort of a tautology: "Here's my clever way to get the user to run my code. Step 1: Write some code. Step 2: Get the user to run it."

Of course, if this corrupted EXE file created other types of problems, such as crashing Explorer or triggering a buffer overflow when the user tried to view its properties, then you'd be onto something. Or if you could somehow avoid detection by not altering the digital signature, then that'd be interesting as well. But if the only way to trigger code injection is to run the injected code, then that's not really all that interesting. You just found a roundabout way of creating a Trojan horse.

Comments (22)
  1. Duncan says:

    Where’s the title line from – it sounds familiar but my feeble brain index refuses to find it…

  2. Geoff says:

    Privilege escalation is another big one that you’ve mentioned in the past.

  3. Steve Kemp says:

    The title is from the Hitchikers Guide to the Galaxy:

      "Well didn’t you think of anything? I thought you said you were going to think of something. Perhaps you thought of something and didn’t notice."

      "Oh yes, I thought of something," panted Ford. Arthur looked up expectantly.

      "But unfortunately," continued Ford, "it rather involved being on the other side of this airtight hatchway." He kicked the hatch they’d just been through.

  4. egh says:

    My C compiler can produce similar code. When will Microsoft fix this?

  5. KJK::Hyperion says:

    Actually, Raymond, it’s a valid concern… for antivirus software (not operating systems, of course). It’s a family of techniques, collectively called Original Entrypoint Obfuscation (OEP), that can conceal where, exactly, the malicious code is hidden inside a trojaned/infected executable, making static analysis harder. I humbly suggest you just outed a legitimate, little-documented OEP technique :-)

  6. Curt says:

    When all you have is a hex editor…

  7. Harvey Pengwyn says:

    Do you have any insights as to the thought processes of the submitter? They must in some sense have thought they were doing something different from ‘create program, run it’.

  8. John Hensley says:

    Hyperion, I’ve worked on legitimate applications of entrypoint obfuscation, and this isn’t even close. This is just someone coming to grips with the fact that executables are files and can be modified.

  9. JamesNT says:

    [slashdotter rant]

    When I tie my computer to the bumper of my car with a rope then drag it down the road, all my data is laid bare for all the world to see.

    I DEMAND to know when MS is going to fix this horrific and inexcusable zero-day exploit in Windows.

    [/slashdotter rant]

    JamesNT

  10. Asztal says:

    JamesNT, I suggest you look into using Encrypting File Systems before dragging your computer along the road.

    Regards,

    Fred Freddington,

    IT Security Consultant

    PS. That will be $10,000, please.

  11. danielsn says:

    JamesNT:  Ever seen Zoolander?

  12. Brian says:

    pwnz0rd.exe… I chuckled.  Thank you, Raymond, for this deconstruction of an absurd statement of the obvious.

    "If can get the user to run code… then I can get the user to run code!"  I can see it now:  MS07-052:  Code execution results in code execution.

    Brilliant.

  13. Erock says:

    I’m disappointed there was nothing to put in the nitpicker’s corner. By freely admitting this, does it imply I’m a nitpicker?

  14. Cooney says:

    JamesNT:  Ever seen Zoolander?

    "It’s… in the computer?"

  15. Miral says:

    It’s always funny (although also slightly depressing at the same time) to hear this kind of complete failure to grok security issues.

    Also: HHTG quotes FTW! :)

  16. dsn says:

    nitpick re Miral’s last post: you’re missing at least one G, and possibly one T (depending on whether you believe you need a T for "the".  

  17. Raymond, you might want to read MS07-040, one of the critical vulnerabilities fixed is very similar your allegedly dubious vulnerability.

    Also, given the mind boggling complexity of Windows, it is quite possible that a few of these allegedly non-security holes can be combined into a real security hole.

    BTW, I happen to have seen part of the mail exchange between MSRC and the discoverer of the .NET PE Loader vulnerability and it took quite a lot of convincing before MSRC realized that there was a vulnerability. From the outside this (and your post here) looks very much like arrogance.

  18. Brian says:

    The critical difference with this "vulnerability" and MS07-040 is that in the PE Vulnerability, you are loading managed .NET code that escapes the sandbox and results in arbitrary code execution on the system.  This is an escalation of privilege.  In Raymond’s vulnerability, the user gains no additional privileges; they already had write access to the file.

    Its like putting "del /q /s /f c:" in a batch file and then saying, "Look!  This batch file erased my programs!  Its vulnerable!"  Of course it did.  Thats what you TOLD it to do.

    ps:  When will Microsoft fix the newly discovered "DEL Command can erase files" vulnerability?

  19. cjm says:

    LOL, Just get UAC on the ball:

    "You have opened an application.  Do you want the program to run?"  Allow/Deny

  20. Igor says:

    This idea is not quite original, but I think there still might be something in it.

    Namely, if you as a regular (non-admin) user manage to modify an executable (say system service) and the modified copy gets loaded and executed on next reboot, then you can access the internet and do all sorts of other things you normally couldn’t.

    Raymond said that it would be easier to overwrite a file, but if you overwrite say SPOOLSV.EXE and the user can’t print anymore you have just blown your cover.

    One thing I must admit is that this “exploit” existed a long time ago, viruses used it extensively by inserting themselves into executables and after doing their work, they allowed the original program to run.

    [But that’s hardly a bug in the PE file format, is it? -Raymond]
  21. Myria says:

    This is why Vista 64’s driver signing is pointless from a security standpoint.  In order to load a rootkit, your Trojan must have administrator access already.  If you have administrator access, you’ve already won.

    Administrators that aren’t administrators – Microsoft might as well try to make water not wet.

Comments are closed.

Skip to main content