Windows file execution WTF



  • The other day I made an update to our in-house database app and published it to our update server. Didn't take long for complaints to roll in about the update not working, returning an invalid instruction in NTVDM. I roll back the update and go 'WTF' in my mind....I've done this easily over a hundred times, WTF went wrong?

    Well, what went wrong was, somehow the file permissions got screwed up on the update server. The update mechanism basically is just an apache server with a list of checksummed files, update utility downloads the list of files, then verifies the checksums and downloads the files it needs via HTTP. Easy, simple, works.

    Well due to the permissions issue, the files couldn't be downloaded so the server returns the usual 403 error message for that case, which the update utility happily writes to the file as the actual data. I really need to re-verify the checksum after downloading the file before actually comitting the file as final, oversight on my part that would have prevented this.

    The WTF though is that windows HAPPILY tries to EXECUTE the file just because it has an EXE extension! I mean for crying out loud, hasn't MS learned to do a little validation before trying to run an executable?


  • :belt_onion:

    @Kermos said:

    Didn't take long for complaints to roll in about the update not working, returning an invalid instruction in NTVDM.
    @Kermos said:
    The WTF though is that windows HAPPILY tries to EXECUTE the file just because it has an EXE extension! I mean for crying out loud, hasn't MS learned to do a little validation before trying to run an executable?
    But they do. It returns an invalid instruction in NTVDM




  • @bjolling said:

    But they do. It returns an invalid instruction in NTVDM
    Yeah. Kermos, would you be pissed off at Linux because you can set execute permissions on and run JPG images? EXE tells Windows that you intend to execute this file, and then when it tried it failed for obvious reasons. What more do you expect from it?



  • @Welbog said:

    @bjolling said:

    But they do. It returns an invalid instruction in NTVDM
    Yeah. Kermos, would you be pissed off at Linux because you can set execute permissions on and run JPG images? EXE tells Windows that you intend to execute this file, and then when it tried it failed for obvious reasons. What more do you expect from it?

     

    Well for starters, how about simply validating the EXE header and if it's not valid, give an error message stating that the file is not a valid executable rather than some cryptic 'NTVDM CPU has encountered an illegal instruction' crap?

     

     



  • @Kermos said:

    Well for starters, how about simply validating the EXE header and if it's not valid, give an error message stating that the file is not a valid executable rather than some cryptic 'NTVDM CPU has encountered an illegal instruction' crap?
    Tomato tomahto, Kermos. The exception message is very clear to me, and a message stating "This file is not a valid executable" isn't likely to be understood by end users any more than what is already there.



  • @Welbog said:

    The exception message is very clear to me, and a message stating "This file is not a valid executable" isn't likely to be understood by end users any more than what is already there.
     

    Oh, but 'NTVDM CPU has encoutered blah blah blah' is going to very clearly understood by end users? REALLY? I'd love to meet your end-users!! 

    And it isn't just the end message itself, it also is the fact that it indicates windows is actually trying to execute the file. Am I seriously the only one that thinks that performing validation on an unknown executable piece of code, *before* executing it would be like, a safe sane and GOOD thing to do? 



  • @Kermos said:

    @Welbog said:

    The exception message is very clear to me, and a message stating "This file is not a valid executable" isn't likely to be understood by end users any more than what is already there.
     

    Oh, but 'NTVDM CPU has encoutered blah blah blah' is going to very clearly understood by end users? REALLY? I'd love to meet your end-users!! 

    Try reading Welbog's comment again.  He makes no claims that the NTVDM error message is understandable to end users.@Kermos said:
    And it isn't just the end message itself, it also is the fact that it indicates windows is actually trying to execute the file. Am I seriously the only one that thinks that performing validation on an unknown executable piece of code, *before* executing it would be like, a safe sane and GOOD thing to do? 
    Yes, because it's not a big deal.  Either the file is structured such that it appears to be a valid executable, in which case validation would tell you nothing, or it isn't, in which case validation isn't needed because it'll just fail when run.

     



  • @bstorer said:

    Yes, because it's not a big deal.  Either the file is structured such that it appears to be a valid executable, in which case validation would tell you nothing, or it isn't, in which case validation isn't needed because it'll just fail when run.

    Or, option 3, it isn't a structurally valid file but since the OS attempts to execute it anyway it exploits some weakness to get malware / virus / bad code to execute.



  • @Kermos said:

    Or, option 3, it isn't a structurally valid file but since the OS attempts to execute it anyway it exploits some weakness to get malware / virus / bad code to execute.
    How do you propose the OS validates files? They're binary files, man. Do you think there's some magic part of executable files that says "THIS IS AN EXECUTABLE FILE"? Even if there were, how would you prevent it from being faked?



  • @Kermos said:

    @bstorer said:

    Yes, because it's not a big deal.  Either the file is structured such that it appears to be a valid executable, in which case validation would tell you nothing, or it isn't, in which case validation isn't needed because it'll just fail when run.

    Or, option 3, it isn't a structurally valid file but since the OS attempts to execute it anyway it exploits some weakness to get malware / virus / bad code to execute.

    That was option 1, 'tard.  And no system in the world can defend against it.


  • @Welbog said:

    How do you propose the OS validates files? They're binary files, man. Do you think there's some magic part of executable files that says "THIS IS AN EXECUTABLE FILE"?
    There is.  For DOS exe files it's MZ.  @Welbog said:
    Even if there were, how would you prevent it from being faked?
    Precisely.



  • @Welbog said:

    @bjolling said:
    But they do. It returns an invalid instruction in NTVDM
    Yeah. Kermos, would you be pissed off at Linux because you can set execute permissions on and run JPG images? EXE tells Windows that you intend to execute this file, and then when it tried it failed for obvious reasons. What more do you expect from it?
    I'm reminded of that guy that got all kinds of "users choice" and "best program" awards for his program.  The program was simply a text file that had been changed to .exe.  The text was something mocking the user for trying to execute it.



  • @Kermos said:

    Am I seriously the only one that thinks that performing validation on an unknown executable piece of code, *before* executing it would be like, a safe sane and GOOD thing to do?
    Are you trying to imply that Windows "knows" any piece of code before executing it? 



  • @bstorer said:

    @Welbog said:
    How do you propose the OS validates files? They're binary files, man. Do you think there's some magic part of executable files that says "THIS IS AN EXECUTABLE FILE"?
    There is.  For DOS exe files it's MZ.

    DOS COM files have no header or magic number, they're just code and data that is executed directly.  Windows still supports COM executables, though, by use of the DOS virtual machine.  There is no real validation that can be done on COM files since there is no format to check against.  So Windows is validating that the executables match the PE format, it's just that if that fails it falls back to COM, hence the error message.

     

    I'd say there is a partial WTF here in that Windows still supports COM files.  They should axe support (or at least make it an option off by default) and then have an invalid executable format trigger a more user friendly error message instead of invoking the DOS VM.

     

    Of course, Kermos is wrong in that this check would make things more secure.  Harmful code is harmful code whether it runs in a PE-formatted Windows executable or an unformatted COM executable.



  • @morbiuswilters said:

    DOS COM files have no header or magic number, they're just code and data that is executed directly.  Windows still supports COM executables, though, by use of the DOS virtual machine.  There is no real validation that can be done on COM files since there is no format to check against.  So Windows is validating that the executables match the PE format, it's just that if that fails it falls back to COM, hence the error message.

    I'd say there is a partial WTF here in that Windows still supports COM files.  They should axe support (or at least make it an option off by default) and then have an invalid executable format trigger a more user friendly error message instead of invoking the DOS VM.

     

    Ok that I can perfectly well agree with. I honestly did not think about COM as to me, that crap is so frigging ancient that I don't even understand why it would fall back to that. Come to think of it, I don't even see why it would run any 16-bit code *at all*. Fer crying out loud, I'm running 64-bit OS' these days, drop the 16-bit 'support' already. It's ridiculous.

     @morbiuswilters said:

     

    Of course, Kermos is wrong in that this check would make things more secure.  Harmful code is harmful code whether it runs in a PE-formatted Windows executable or an unformatted COM executable.



    Agreed, harmful code is harmful code and I didn't mean to say or imply that checking an EXE for being correctly formatted would suddenly make it safe. Of course not. I do think though that it eliminates one potential attack vector at the cost of what, a few microseconds if not even only nanoseconds? Worth it as far as I'm concerned. But like you said, it's very well possible that windows already does this and it just doesn't look that way due to it falling back to COM.

     



  • @Kermos said:

    I do think though that it eliminates one potential attack vector at the cost of what, a few microseconds if not even only nanoseconds?
    What attack vector?!  Leaving aside COM files, it's as I've said before: either the code is an executable, in which case a validator won't find anything wrong, or it's improperly formatted, in which case you'll get an error message when you try and run it anyway.



  • @bstorer said:

    @Kermos said:

    I do think though that it eliminates one potential attack vector at the cost of what, a few microseconds if not even only nanoseconds?
    What attack vector?!  Leaving aside COM files, it's as I've said before: either the code is an executable, in which case a validator won't find anything wrong, or it's improperly formatted, in which case you'll get an error message when you try and run it anyway.

    More correctly, the file format has to be validated and is.  Executables can contain great deals of metadata used by the kernel (such as linkings and so-forth) and the kernel must check that the values present are reasonable.  By design, unless you want your OS to be completely insecure you must validate the metadata in an executable before the kernel makes use of it.  So if the executable wasn't validated that would be a potential attack vector.



  • @morbiuswilters said:

    More correctly, the file format has to be validated and is.  Executables can contain great deals of metadata used by the kernel (such as linkings and so-forth) and the kernel must check that the values present are reasonable.  By design, unless you want your OS to be completely insecure you must validate the metadata in an executable before the kernel makes use of it.  So if the executable wasn't validated that would be a potential attack vector.
     

    Thanks, that was exactly what I was referring to. Due to windows attempting to treat the file as a COM file, I thought it *wasn't* doing that last part. I just simply didn't think of COM files.

    So in the end, I suppose I was wrong and hey, that's been known to happen and in this case I'm relatively happy about having been wrong.

    The whole COM file thing though is a WTF.

     



  • @Kermos said:

    Fer crying out loud, I'm running 64-bit OS' these days, drop the 16-bit 'support' already. It's ridiculous.

    But 16 bit support [i]is[/i] dropped in 64-bit OSes. I think.


  • Garbage Person

     Not the OS directly, per se. The PROCESSOR, yes. The AMD64 spec says that the CPU has two modes: 16/32bit mode, and 32bit/64bit mode - it either won't execute the new 64bit instruction set or it won't execute the 16bit instruction set - but it'll execute the 32bit instruction set in both modes. If you run 16bit software in VMs on 64bit-mode CPUs, you'll notice that things are CONSIDERABLY slower than running with the CPU in legacy mode. Mind you the last time anybody wrote 16bit software, CPUs were so much slower that the emulation layer is still lightyears faster than it's looking for..

     

    Anyway, end result - AMD64-compiled Windows has to run in 32/64 mode and cannot execute 16bit code (honestly I'm surprised Microsoft didn't build an emulation layer into Vista to work around the occasional problems that crop up as a result.)



  • @Kermos said:

    @bstorer said:

    Yes, because it's not a big deal.  Either the file is structured such that it appears to be a valid executable, in which case validation would tell you nothing, or it isn't, in which case validation isn't needed because it'll just fail when run.

    Or, option 3, it isn't a structurally valid file but since the OS attempts to execute it anyway it exploits some weakness to get malware / virus / bad code to execute.

     

     

    If it were malware, the hacker has won once he gets the user to click on it.  What would be the point of a hacker writing malware that is not a valid executable?  That would be like a burglar breaking into your house and not stealing anything.



  • @Kermos said:

    Ok that I can perfectly well agree with. I honestly did not think about COM as to me, that crap is so frigging ancient that I don't even understand why it would fall back to that. Come to think of it, I don't even see why it would run any 16-bit code *at all*. Fer crying out loud, I'm running 64-bit OS' these days, drop the 16-bit 'support' already. It's ridiculous.

     

    Microsoft cares a great deal about backwards compatability.  That's why people are more willing to upgrade to the newest version of Windows than a lot of other software that is extremely important to them.  

    When users start experiencing not being able to run their old programs, Microsoft will have problems pushing the new versions of Windows.  Hence, less profit.



  • @tster said:

    Microsoft cares a great deal about backwards compatability.  That's why people are more willing to upgrade to the newest version of Windows than a lot of other software that is extremely important to them.  
     

    Haven't heard much about Vista, have you?

     



  • I don't know, I'd say that if 3 years after the OS release you still haven't fixed the bugs in your software yet it's your own goddamn problem. Really, the stuff Vista causes problems with is usually stuff your code shouldn't have been doing in the first place.


  • Garbage Person

    @Dudehole said:

    I don't know, I'd say that if 3 years after the OS release you still haven't fixed the bugs in your software yet it's your own goddamn problem. Really, the stuff Vista causes problems with is usually stuff your code shouldn't have been doing in the first place.

    This.

     All the retarded developers who wrote software that had to be run with administrative rights are to blame for Vista's "problems" - aside from a few software packages that had hardware drivers as a component, anyway. But then again when World+Dog switched from 98SE to XP, we had problems with that same class of software anyway. It's just that shitty programmers who crutch on admin are a hell of a lot more common than developers who can interface or emulate hardware, thus we have Vista's "problems"



  • AFAIK, any file is a valid MS-DOS executable (.COM file), however Windows shouldn't be trying to run a .EXE file as if it was .COM, and .EXE files have a magic number ("MZ") which it really should check.

    Once on a school computer, I opened notepad and entered "MZ000000000000000000000000000000000000000000" etc and saved it as an EXE file. Then I ran it. It gave me two illegal instructions (which I clicked Ignore to, just to see what would happen) and then something like "Cannot access drive I: Abort, retry, ignore?"



  • @immibis said:

    AFAIK, any file is a valid MS-DOS executable (.COM file), however Windows shouldn't be trying to run a .EXE file as if it was .COM, and .EXE files have a magic number ("MZ") which it really should check.

    Once on a school computer, I opened notepad and entered "MZ000000000000000000000000000000000000000000" etc and saved it as an EXE file. Then I ran it. It gave me two illegal instructions (which I clicked Ignore to, just to see what would happen) and then something like "Cannot access drive I: Abort, retry, ignore?"

    COM executables do not have to have the .COM extension.  Also, MZ executable is an older DOS format and there are other executable types that can have the .EXE extension, like PE.  So, basically, you are wrong.



  • @morbiuswilters said:

    @immibis said:

    AFAIK, any file is a valid MS-DOS executable (.COM file), however Windows shouldn't be trying to run a .EXE file as if it was .COM, and .EXE files have a magic number ("MZ") which it really should check.

    Once on a school computer, I opened notepad and entered "MZ000000000000000000000000000000000000000000" etc and saved it as an EXE file. Then I ran it. It gave me two illegal instructions (which I clicked Ignore to, just to see what would happen) and then something like "Cannot access drive I: Abort, retry, ignore?"

    COM executables do not have to have the .COM extension.  Also, MZ executable is an older DOS format and there are other executable types that can have the .EXE extension, like PE.  So, basically, you are wrong.

    Most PE files are valid MZ executables. This includes the "MZ" magic number and the file header. The PE file format is compatible with MZ, so you can have a Windows program and a DOS program in the same .EXE file (I believe regedit.exe on windows 98 did this, where running it from DOS (as MZ) allowed you to merge .reg files and running it in Windows (as PE) gave you the GUI.

     

    [url]http://win32assembly.online.fr/pe-tut1.html[/url]
    [url]http://en.wikipedia.org/wiki/EXE#Other[/url]

     



  • @immibis said:

    @morbiuswilters said:

    @immibis said:

    AFAIK, any file is a valid MS-DOS executable (.COM file), however Windows shouldn't be trying to run a .EXE file as if it was .COM, and .EXE files have a magic number ("MZ") which it really should check.

    Once on a school computer, I opened notepad and entered "MZ000000000000000000000000000000000000000000" etc and saved it as an EXE file. Then I ran it. It gave me two illegal instructions (which I clicked Ignore to, just to see what would happen) and then something like "Cannot access drive I: Abort, retry, ignore?"

    COM executables do not have to have the .COM extension.  Also, MZ executable is an older DOS format and there are other executable types that can have the .EXE extension, like PE.  So, basically, you are wrong.

    Most PE files are valid MZ executables. This includes the "MZ" magic number and the file header. The PE file format is compatible with MZ, so you can have a Windows program and a DOS program in the same .EXE file (I believe regedit.exe on windows 98 did this, where running it from DOS (as MZ) allowed you to merge .reg files and running it in Windows (as PE) gave you the GUI.

     

    http://win32assembly.online.fr/pe-tut1.html
    http://en.wikipedia.org/wiki/EXE#Other

    How is any of what I said incorrect?  You said .EXE files shouldn't be run as COM executables which is simply incorrect.  COM executables can have the .EXE extension.  I never said MZ and PE weren't compatible, but they are different formats.  Just because PE allows MZ programs to be embedded as a fallback for MS-DOS does not make them the same format.  Please learn to read.



  • @morbiuswilters said:

    @immibis said:

    @morbiuswilters said:

    @immibis said:

    AFAIK, any file is a valid MS-DOS executable (.COM file), however Windows shouldn't be trying to run a .EXE file as if it was .COM, and .EXE files have a magic number ("MZ") which it really should check.

    Once on a school computer, I opened notepad and entered "MZ000000000000000000000000000000000000000000" etc and saved it as an EXE file. Then I ran it. It gave me two illegal instructions (which I clicked Ignore to, just to see what would happen) and then something like "Cannot access drive I: Abort, retry, ignore?"

    COM executables do not have to have the .COM extension.  Also, MZ executable is an older DOS format and there are other executable types that can have the .EXE extension, like PE.  So, basically, you are wrong.

    Most PE files are valid MZ executables. This includes the "MZ" magic number and the file header. The PE file format is compatible with MZ, so you can have a Windows program and a DOS program in the same .EXE file (I believe regedit.exe on windows 98 did this, where running it from DOS (as MZ) allowed you to merge .reg files and running it in Windows (as PE) gave you the GUI.

     

    http://win32assembly.online.fr/pe-tut1.html
    http://en.wikipedia.org/wiki/EXE#Other

    How is any of what I said incorrect?  You said .EXE files shouldn't be run as COM executables which is simply incorrect.  COM executables can have the .EXE extension.  I never said MZ and PE weren't compatible, but they are different formats.  Just because PE allows MZ programs to be embedded as a fallback for MS-DOS does not make them the same format.  Please learn to read.

      I never said it didn't. I said it shouldn't.

Log in to reply