Dubious security vulnerability: Copying a program and running the copy


This wasn't an actual security vulnerability report, but it was inspired by one. "If you take the program XYZ.EXE and you rename it or copy it to a new name that contains the letters XYX, then you can trigger a buffer overflow in the renamed/copied version of XYZ.EXE due to a bug in the way it parses its own file name in order to generate the names of its auxiliary files."

While that's a bug, and thanks for pointing it out, it is not a security issue because there is no elevation of privilege. Sure, you could rename or copy the program and run it, but if you have permission to do that, you may as well do it the easy way: Instead of copying XYZ.EXE and running it, just copy pwnz0rd.exe and run it! Either way, it's just a case of you attacking yourself. You did not gain any privileges.

Renaming or copying a file requires FILE_ADD_FILE permission in the destination directory, and if you have permission to add files to a directory, why stop at just adding files that are copies of existing files? You can add entirely new files!

In other words, instead of copy XYZ.EXE XYX.EXE, just do copy pwnz0rd.exe XYX.EXE.

This is a variation of the dubious vulnerability known as Code execution results in code execution.

Now, this would be an actual vulnerability if you could somehow redirect attempts by other people to run XYZ.EXE from the original to your alternate XYX.EXE instead. But that would be attacking the redirection code, not attacking XYZ.EXE itself. Because if you can fool somebody into running XYX.EXE instead of XYZ.EXE, then you may as well fool them into running pwnz0rd.exe. It's not like the Create­Process function performs a hard drive scan looking for a program whose name is similar to the one you requested and running that other program instead.

Comments (30)
  1. Joshua says:

    Because some people configure their systems to only allow signed binaries by certain signatories to run.

    I personally think that practice sucks and is of dubious value but …

  2. Brian_EE says:

    The easiest way to eliminate security vulnerabilities is to eliminate the digital computer, OS, and applications all together. The Fire Control system on the USS North Carolina used a totally analog computing solution. You protect privelege elevation by protecting physical access, and a guard with rifle is pretty effective.

  3. Tim says:

    @Brian, you remind me of a quote saying something like the most secure system being unusable. Couldn't find that one after a quick search, but did find this one from Gene Spafford:

    "The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards – and even then I have my doubts."

  4. DWalker says:

    The user is not really reporting a security vulnerability; they are reporting an instance of poor programming.  They just don't recognize the difference.

  5. Skyborne says:

    @Brian_EE Why not go one step further and eliminate the USS North Carolina?  You won't need a Fire Control system if there is no ship to catch fire.

  6. Adam says:

    As Joshua said, this could be a vulnerability if the administrator has enabled application whitelisting of one form or another, if the whitelisting is done by signatures or fingerprints.  It's a way to make a whitelisted program do something unexpected.

  7. Brian_EE says:

    @Skyborne: "Fire Control" == "Aiming the Big Guns Towards the Bad Guys and Making them Go BOOM". Thus the importance of preventing privelege escalation.

  8. Kevin says:

    "It's not like the Create­Process function performs a hard drive scan looking for a program whose name is similar to the one you requested and running that other program instead."

    No, but the shortcut fixup code does…

    [In order to trigger shortcut fixup, you have to delete the original and create the rogue version. If you can do that, then you're already on the other side of the airtight hatchway: Delete the original and replace it with the rogue version. -Raymond]
  9. Skyborne says:

    @Brian_EE: derp, my bad.  (You know, I did wonder, just a bit, why the fire extinguishing system would need an armed guard… but clearly it didn't sink in.)

  10. Myria says:

    I agree with Adam and Joshua here.  It depends on the definition of "privilege".  If code signing is a security boundary, then this is a security exploit.

    It's like my exploit with PowerShell to load unsigned native code DLLs on Windows RT.  My exploit is definitely a case of "code execution results in code execution", yet it's clearly breaking a boundary: that only Microsoft-signed code is allowed to run in desktop mode on Windows RT.

  11. Random832 says:

    What if the program is whatever the equivalent of set-UID on windows, and the same bug can be triggered by passing the altered name as command line without renaming the file? (I don't know if this is possible on windows)

  12. Joshua says:

    @Random832: Only if Cygwin is installed AND cygrunsrv is running AND setuid is enabled AND the launching program is linked against cygwin1.dll. And even then it's a fool of a sysadmin who turns on the setuid bit on any binary not designed for it.

  13. foo says:

    @Skyborne. I read your comment as a statement about war in general. "Why not go one step further and eliminate the need for humans to build things to kill one another." But that wouldn't be one simple/small step.

  14. Brian says:

    Thank you Raymond, same Brian from that 2007 comment here and I laugh every time I see one of those references.  I try to promote your "airtight hatchway" model for defining a security vulnerability whenever I have the chance.

  15. cheong00 says:

    I can think of a case that where it might lead to problem.

    Say when XYZ.EXE has a function that download update from whatever location to local folder (it ought to be data file only and the code verify the filenames does not end with EXE), they can actually trigger the bug by placing XYZ<whatever>.DAT on the server. But suppose there are some way to trigger arbitrary code execution using the buffer overflow bug…

    Okay, maybe I'm thinking too much.

  16. @cheong00 says:

    I think you are thinking too much :)  You said suppose xyz has a function that will execute arbitrary code when tickled the wrong way (in particular, when invoked under a different name).  The point Raymond is trying to make is that you have to make a copy of it to tickle it, so you already have the power to execute arbitrary code.  Or am I misunderstanding your question?

  17. cheong00 says:

    I'm saying that XYZ.EXE itself will download some data files from the website. The XYZ.EXE itself is not changed. The XYZ.EXE places files like XYZ<whatever>.DAT to current folder, and it triggered the buffer overflow problem mentioned in the post. Now if the <whatever> part contains bytes that are runnable, and of you know the overflowed part is on some code path that will be triggered routinely, you might successfully trick the XYZ.EXE to run the code bytes you injected.

    Of course with NX like technology the possibility of going wrong this way is very small, but consider NX is opt-in by default on Win7 or so I'm not so certain.

    [But how do you trigger the overflow? You have to trick the user into running XYX.EXE. If you can do that, then just trick them into running pwnz0red.exe. -Raymond]
  18. Sven2 says:

    What about creating a hard link with another name to the file? Would that work, or do hard links require special permissions as well?

    If hard links require admin: Could you have another device (like an external USB drive) prepared on another computer where you have admin rights and that device would contain the hard link to the file?

    I also wonder if the bug could also be triggered if the string was part of the path name. Then you could start the file as C:/XYX/../Progra~1/XYZ/XYZ.EXE.

    [If you can convince someone to run E:XYX.EXE or C:XYX/..Progra~1XYZXYZ.EXE, then why not simply convince them to run E:pwnz0red.exe? -Raymond]
  19. Engywuck says:

    hard links can only point to files in the same filesystem, so your USB stick would need XYZ.exe on it. But when you already can execute code on some random USB stick…

  20. cheong00 says:

    [But how do you trigger the overflow? ]

    That's why I say "[strike]of[/strike]if you know the overflowed part is on some code path that will be triggered routinely". I don't know XYZ.EXE's nature. If it's a common application that will be run from time to time (like Notepad++), you can be certain that some day it will be run by some user.

    If XYZ.exe is not part of a larger package like Office, the existance if the EXE itself is self-evident that it will be run by some user some day.

    Now if the attacker can compromise your system by pwning some web server that's know not to be used to store program updates, I'd count that as security vulnerability.

    [The overflow is "in the way it parses its own file name". So in order to attack it, you need to alter the file name that is used to execute the program. -Raymond]
  21. Gabe says:

    So if you have a means to remotely copy a file to a name that you control and then invoke that program, then it's a security vulnerability. If you can put arbitrary bits on the disk and run them as a program, then it's no big deal.

    [If you can put arbitrary bits on the disk and run them as a program, then that's your problem. The fact that the arbitrary bits are byte-for-byte identical to some other program is not the problem. -Raymond]
  22. Sven2 says:

    > [If you can convince someone to run E:XYX.EXE or C:XYX/..Progra~1XYZXYZ.EXE, then why not simply convince them to run E:pwnz0red.exe? -Raymond]

    A malicous program that is already running in user space but wants admin could do this. Users would just see the "XYZ.EXE asks for elevation" prompt, with XYZ.EXE being a program they know and properly signed by Microsoft, so they think it's alright and grant permission. It wouldn't be a code execution bug but still a potential privilege escalation vulnerability.

  23. DWalker says:

    If I can get someone to take a pill that I hand to him (that is, eat a capsule of unknown medicine), it doesn't matter that I have camouflaged the pill by painting it another color, or if I tell him it's aspirin, or what brand markings I paint on it.  (Plus, I hate analogies.)

  24. Joshua says:

    I was wondering if there was a way to trip the problem via shortcut resolution (making the original disappear is in fact not unfeasible) but it turns out if you can get the tampered one to run, the only reason to use the original bits is trying to overcome white-listing by signature or hash.

    I think both Raymond and I are amazed at the difficulty in comprehending this.

    Incidentally the path involved in getting the shortcut resolver to fall for it is straight into dubious security vulnerability territory. I suspect it's akin to having a world-writable location far down the list in PATH.

  25. Anonymous Coward says:

    @Sven2: So simply rename pwnz0rd.exe to XYZ.EXE.

  26. Sven2 says:

    @Coward: Then the elevation prompt will be "XYZ.EXE asks for elevation. Publisher: NOT TRUSTED". But using that vulnerability and injecting code into the executable of a trusted vendor, you can make it "XYZ.EXE asks for elevation. Publisher: Trusted Vendor (signed)".

  27. Random832 says:

    "even then it's a fool of a sysadmin who turns on the setuid bit on any binary not designed for it." – something can be designed for it but still have a bug.

  28. Random832 says:

    Also, does Windows itself (without using cygwin or SFU or anything) not have a functionality equivalent to the setuid bit?

  29. Dennis says:

    The converse of this is that "updater can replace 'z' with 'x' when making a copy" goes from a silly bug to a security vulnerability.

  30. Someone says:

    @Random832 "Also, does Windows itself (without using cygwin or SFU or anything) not have a functionality equivalent to the setuid bit"

    No it does not have something like setuid.

    The only thing that comes near is an application that prompts via UAC for performing an administrative action. But this is only effective, if the user is a member of the Administrators group and if UAC is enabled at all.

    If the application does not use UAC for elevation, but is not run by an administrator, the action is denied up-front. If the application is using UAC for elevation, either the user is prompted to enter the credentials of an Administrator account, or he is prompted to confirm that he allows the action. (Problem is, that it is not clear WHAT action the application will really do.)

Comments are closed.

Skip to main content