#1
  1. No Profile Picture
    Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Apr 2003
    Posts
    15
    Rep Power
    0

    Visual C++ malicious input


    If I write a program that inputs a file from a user (all types are acceptable), can someone give my program a file that could do damage to my computer? Damage is defined as harming my compter, filling up memory and overloading the buffer, causing me to restart, etc etc.

    Will an .exe with a virus execute when it is opened from the compiler? I wouldn't normally open .exe's but I am curious.

    Can someone write a script in .txt (or any other extenesion) that executes/runs that could do damage?

    Thanks for your thoughts!
  2. #2
  3. not a fan of fascism (n00b)
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Feb 2003
    Location
    ct
    Posts
    2,756
    Rep Power
    95
    i'll just take a stab at this since nobody else answered. i dont think a malicious file could do any damage. If your opening it for "read" and it is an exe, i would think that you'd get some type of error message. as far as filling up buffers/memory, that doesnt seem likely either as long as you do proper bounds checking when reading in your file. perhaps in your read loop you could specify a max # of bytes to be read in. now of course i could be entirely wrong:D, but that's my thought on the subject
  4. #3
  5. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,145
    Rep Power
    2222
    As far as I know, no one has broken free of the "gotta be executable" restriction. As long as your program or your system doesn't try to execute or interpret the file, it cannot do harm.

    On the negative side, the range of files that could be executable has been increasing. The most obvious examples are MS Office files which contain macros, so that documents and spreadsheets can be malicious, especially since those macros can make changes to your registry. But the old adage still holds: it's gotta be executable.

    Now it's time to get up on my soapbox. Just about the most bone-head idiotic thing that Microsoft has ever done has been to give you the option of hiding file extensions and then to make that the default setting on all their systems! That's what most of the email worms and trojans are taking advantage of. Eg, they send you an attachment called "stuff.doc.pif" and all you see is "stuff.doc", so you double-click to open the "document" and instead you just told the system to run that executable file. Those extensions are valuable information that you need to protect yourself and it is extremely irresponsible to hide that information from you. I urge everybody to go into their Folder Options and turn that option off!

    OK, I'm putting my soapbox away now ... until next time.
  6. #4
  7. No Profile Picture
    Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Apr 2003
    Posts
    15
    Rep Power
    0
    As long as your program or your system doesn't try to execute or interpret the file, it cannot do harm.
    I guess that is my question. When I hit execute in my compiler and the supplied input is an .exe, will it try to execute it or interpret it?
  8. #5
  9. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,145
    Rep Power
    2222
    Originally posted by henslecd
    I guess that is my question. When I hit execute in my compiler and the supplied input is an .exe, will it try to execute it or interpret it?
    I guess I don't understand what operation you are describing. Most input files to a compiler will be source files (text) or libraries (object, but not yet executable) or graphics resources (binary, but not executable). Your compiler uses those inputs to generate an executable file which, if you command it, would execute. But in that case, you had created it and should know whether you had put any malicious code in it or not.

    I guess what I don't understand is under what circumstances you would be trying to run a foreign .exe file from within your development environment.
  10. #6
  11. No Profile Picture
    Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Apr 2003
    Posts
    15
    Rep Power
    0
    I wouldn't. I am just trying to get a feel of what the compiler does when executing the program. If it reads in a file, does it open it? Or does it just read it. If i had a program that says...

    cout << "Enter an input file> ";

    cin >> input;

    ifstream fdates(input.data());

    etc...


    If someone entered an .exe or anything else, would it execute as it is or just be read, nothing more?
  12. #7
  13. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,145
    Rep Power
    2222
    It would just read it as data ... assuming that I read your example correctly -- I'm an old curmudgeon when it comes to iostreams and never could see the use of them so long as I have printf.

    In order for an executable file to execute, the OS has a number of things to set up, including allocating a memory space to it and doing the final address-fixing -- I knew it fairly well for DOS and I assume that Windows does some of the same kind of stuff. Then the OS needs to do a jump to the program's entry point. Take a look at the format of the EXE file header some time to get an idea of what the OS needs to know about the executable to be able to run it.

    OTOH, if your program just opens it and reads it like a file, then the old adage of "bits are bits and bytes are bytes" comes into play. Every piece of data in the computer are just bits and bytes. What they are interpreted as being and how they are handled depends on what you told the computer that they are. If you tell the computer that they're instructions to be executed, then it will try to do that. If you tell the computer that they are binary data to be read, then it will try to do that and it will try to interpret that binary data as you tell it to (ie, which bytes are floating point, which are integer, etc).

    Here's a neat old trick I learned from DOS. In Windows you keep your program's settings in the registry or in an ini file. You can keep updated settings in the exe file itself:
    1. Place those settings in a struct that starts with a unique character string.
    2. While running the program, change a setting.
    3. In response, the program opens its own exe file and scans for that unique character string.
    4. Since you figured out ahead of time the offset from the unique string to the setting value in question, go to that location in the file, update it with the new setting, save it to disk and close the file.

    Now that's an example of an executable being treated purely as data.

    NOTE: I've only used that trick in Pascal, but I haven't tried it yet in C. I would assume that C keeps initialization data for structs together in the struct's format, but I cannot guarantee it.
    Last edited by dwise1_aol; June 17th, 2003 at 08:13 PM.
  14. #8
  15. No Profile Picture
    Offensive Member
    Devshed Novice (500 - 999 posts)

    Join Date
    Oct 2002
    Location
    in the perfect world
    Posts
    622
    Rep Power
    27
    >>1. Place those settings in a struct that starts with a unique character string.
    2. While running the program, change a setting.
    3. In response, the program opens its own exe file and scans for that unique character string.
    4. Since you figured out ahead of time the offset from the unique string to the setting value in question, go to that location in the file, update it with the new setting, save it to disk and close the file. <<

    Never tried this. I always use a second app to update from a remote site or use the reg.

    How can the exe save the modifications to itself WHILE it is being run? ie sharing violoation

    beware in number 4 that the struct has not been padded if using the sum of its components
    ie sizeof(STRUCT) != SUM ( sizeof(components) )
    The essence of Christianity is told us in the Garden of Eden history. The fruit that was forbidden was on the Tree of Knowledge. The subtext is, All the suffering you have is because you wanted to find out what was going on. You could be in the Garden of Eden if you had just kept your f***ing mouth shut and hadn't asked any questions.

    Frank Zappa
  16. #9
  17. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,145
    Rep Power
    2222
    Originally posted by TechNoFear
    >>1. Place those settings in a struct that starts with a unique character string.
    2. While running the program, change a setting.
    3. In response, the program opens its own exe file and scans for that unique character string.
    4. Since you figured out ahead of time the offset from the unique string to the setting value in question, go to that location in the file, update it with the new setting, save it to disk and close the file. <<

    Never tried this. I always use a second app to update from a remote site or use the reg.

    How can the exe save the modifications to itself WHILE it is being run? ie sharing violoation
    Very simple. Once the exe has been loaded and has started to execute, the file is no longer open. The program has been loaded into RAM and is being run from there, not from the hard disk.

    Of course, the final arbiter in any matter is the computer, so what would be needed would be a test program to verify that it can still be done. I had done it successfully, but that was 11 years ago under DOS. And Borland's TUI IDEs (Turbo/Borland Pascal & Turbo/Borland C/C++ - non-Windows) used that same trick and they still work under Windows, as far as I can tell.

    So, some time when I'm bored and can't fall asleep ...

    Originally posted by TechNoFear

    beware in number 4 that the struct has not been padded if using the sum of its components
    ie sizeof(STRUCT) != SUM ( sizeof(components) )
    Exactly what I was thinking when I decided to mention that I had only done it in Pascal and had never tried it in C. In fact, I learned the trick from the very last Pascal book I had ever bought -- I forget the name now.

    It would be a very good idea to view a hex dump of that portion of the .exe file -- I use Vernon D. Buerg's LIST utility in Windows and xxd in both Windows and Linux, but Windows still has the old debug command (I was surprised to find edlin still on Win2k and WinXP). Both struct packing and byte order are potential issues that the programmer needs to be aware of to make this work, as well as the effects that recompiling to migrate from one platform to another would have. Visual C++ v1.52 has a pack pragma, but I did not find anything similar in the libc help.

    In short, this is not something that should be slapped together quickly nor that you should do based on assumptions. Examine that data structure thoroughly as you map out exactly what is where. BTW, I also would recommend against reading that struct in as a struct -- again because of padding problems -- but rather work it as individual bytes.

    NOTE:
    Another consideration not really touched upon is whether we would actually want to use this method in real life. Although I can see where it could be useful in a registration-enforcement scheme (stow a "magic" value in a specific variable that you then test upon startup), there are safer and more generally accepted ways to maintain an application's configuration settings. So for most cases, this is much more of "neat trick" than it is a recommended practice.
    Last edited by dwise1_aol; June 18th, 2003 at 01:08 PM.
  18. #10
  19. No Profile Picture
    Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Apr 2003
    Posts
    15
    Rep Power
    0
    Thanks for the help. I don't have enough experience right now to understand a lot of what you are saying but I will research a lot fo what you said and see how it goes.
  20. #11
  21. No Profile Picture
    Offensive Member
    Devshed Novice (500 - 999 posts)

    Join Date
    Oct 2002
    Location
    in the perfect world
    Posts
    622
    Rep Power
    27
    >>Once the exe has been loaded and has started to execute, the file is no longer open. The program has been loaded into RAM and is being run from there, not from the hard disk.

    AFAIK.

    The system creates a memory map for the exe (basically mapping the bytes in the file to virutal memory).
    While this mapping is open, the system denies other threads and processes from opening a "write" access handle to the mapped file, so you can't alter the exe while it is running.

    You could open the memory map with write access (if you get the shared access right) but would probably need to use assembler and any changes would not be saved to the disk version once the exe was closed.
    The essence of Christianity is told us in the Garden of Eden history. The fruit that was forbidden was on the Tree of Knowledge. The subtext is, All the suffering you have is because you wanted to find out what was going on. You could be in the Garden of Eden if you had just kept your f***ing mouth shut and hadn't asked any questions.

    Frank Zappa

IMN logo majestic logo threadwatch logo seochat tools logo