It rather involved being on the other side of this airtight hatchway: If they can inject code, then they can run code

One category of the dubious security vulnerability is designing an insecure system, putting together an exploit, and then blaming one of the components of the exploit rather than the insecure system in the first place.

I have found a critical security vulnerability in the XYZ scripting object which permits modifying files on the Web server itself.

To effect this exploit, write a script which instantiates the control and use the Save method to tell it to save its contents. The Save method does not attempt to block directory traversal, so you can pass any path to the Save method and overwrite any file on the server.

To deploy this exploit, find a Web server which has a writeable directory that also has execute permission and which executes scripts as SYSTEM. Upload the script to the server, and then from another machine, visit the Web server to view the page you just uploaded. The Web server will execute the script as a server-side script, and the target file will be overwritten.

Well, yes, this whole set-up is definitely vulnerable, but why are you blaming the XYZ scripting object? For one thing, you can do exactly the same thing with any other scripting object that can write files. For example, just use the FileSystemObject object. In fact, that object is even better than the XYZ object, because the file system object lets you control what is written!

But the real security vulnerability is that the person who set up the Web site did so insecurely. If you let untrusted users upload scripts to the server and configure the server to execute them as SYSTEM without restriction, then naturally those users can upload scripts that do dangerous things to the server. That's not the script's fault; it's the fault of the person who set up the Web server to execute those scripts in such an insecure manner in the first place! (You might have a case if the insecure configuration is the default, but I don't know of any modern servers that do.)

Comments (20)
  1. W says:

    Possibly the script is sandboxed and the filesystem object enforces the access controls. But the vulnerable scripting object doesn’t enforce them.

    If the script already executes with the privilegues of the process without internal access control(like all native code does) then the vulnerability is of course not in the scripting object.

  2. Paul says:

    There’s only one way to make a sever secure.

    Remove it from the network, lock it in a solid cage and throw away the key.

  3. SMW says:

    "There’s only one way to make a sever secure.

    Remove it from the network, lock it in a solid cage and throw away the key."

    But don’t include any vents, or else Tom Cruise will rappel down from above and steal your data.

  4. Henke37 says:

    @W Permissions are done on an user basis by the OS. This is outlined in some of the other crackpot vulnerability posts.

  5. arnshea says:

    Hilarious!  Almost as good as a "vulnerability" description that starts with "Run this script from an elevated command prompt…."

  6. Mark says:

    Henke37: W is right. If this object is marked safe for scripting, it’s additionally guaranteeing it can’t execute arbitrary code, and shouldn’t be able to write to arbitrary locations.

  7. _ says:

    Raymond, i am sorry you have to read the stupid comments above. It is so embarrassing.

  8. Anonymous says:

    This reminds me of a common weakness across several systems I used to see trying to implement "security" features.

    These systems would have a "login" dialog, or perhaps some kind of kiosk UI.  They managed to block Ctrl-Alt-Del and Ctl-Shift-Esc.  But not F1.

    F1 would open the help viewer, then you could go through the motions of asking the help viewer to open a different .hlp file.  (I guess this would be .chm today.)  In the file open dialog, you could browse to system32 and right-click on cmd to open it.

    I saw a similar weakness in a kiosk system that used IWebBrowser2 to present its UI.  You could right-click the control, select "view source", and get to the shell via notepad.

    Is this a bug in the shell, the help viewer, or IWebBrowser2?  Well, if the program wanted to lock down the user, they shouldn’t have provided these entry points to begin with.  It’s not reasonable to expect the authors of reusable components to do your security work for you.

  9. Rick M. says:

    [Golf claps for a Doug Adams quote]

  10. Jeff Tyrrill says:


    Your comments are a huge insult to those who design, improve, and set up systems which are actually secure.

    Or did you just intend to interrupt this thread with your "humor" while people who understand the issues discuss them seriously?

  11. frymaster says:

    "Your comments are a huge insult to those who design, improve, and set up systems which are actually secure"

    no, because anyone who actually designs systems that try to be secure would be nodding along to that

    note that I said "try to be secure" because those in the know also recognise no general-purpose internet-enabled system can ever be totally secure

  12. Crescens2k says:

    Mark, safe for scripting shouldn’t make that guarentee. As an administrator the mindset shouldn’t be, "The control says it is safe, I will blindly use it" but "The control says it is safe so I will test it out and confirm it before I allow it to be used".

    Lets face it, would a malicious control advertise "I’m unsafe, if you use me I will grab personal data and send it off to some one for them to use for bad things"?

  13. a random passerby says:


    Most of my friends who are into computer security would agree with Paul. "Perfect network security" is like "bug-free software". I’m sorry, but it doesn’t exist.

    If you’re so certain that you can make it happen, though, enough so that you feel the need to be offended by a little security humor, then by all means apply for a job at Google. Based on recent events, they’d probably be in the market for security gurus right about now.

  14. arnshea says:

    @random passerby, Hear Hear.

    @Crescens2k, testing is good but testing has its limits.  Every conditional in a program represents a potential vulnerability.  Lowballing 10% of lines of code to be conditionals/branches and at 1000 lines of code you’re already talking about 2^100 possible states.

    Throw in code injection, whether through dynamically loaded libraries or dynamically generated code, and, as they say in parts of New York City: fuggedaboutit.

  15. Dan says:

    @Anonymous HTML Help can’t open other CHM files from its UI, you’d have to specify them on the command line for HTML Help so it wouldn’t help you here (pun not intended).

    @Jeff Tyrrill I actually find Paul’s comment accurate, and not insulting at all.  You, on the other hand, seem a bit naive.  It is impossible to have a 100% secure server.  There will always be bugs somewhere in a sufficiently complicated system.  Even if you magically make a system with no bugs that is 100% secure… you have to have human users otherwise the system isn’t very useful.  Those users will always be the weakest links, perfect system or not.

    Hmm… why is the capcha textbox autocompleting?  It needs autocomplete="off" on its tag attributes, or whatever it is. :(

  16. Crescens2k says:


    I guess I need to apologise since I seemed to have been totally unclear as to what I was getting at. The whole tone of that post was not how the code should be secure but actually how a system administrator should be aware of what is going on and lock things down apropriately.

    It was suggested to use and check for a components safe for scripting state but I said that is not possible since you can’t rely on safe for scripting since it could be possible for a component to say, yes I am safe and then do bad things.

    But even with a component which isn’t malicious it is always possible to do accidental bad things. So the best thing to do is have someone figure out these problems and then make sure that if you do use the component, it should be used in such a way that the component will not cause any problems. (Ie, by running the process with reduced privilages).

    In this case nothing beats having a properly locked down server with properly configured ACLs on the file system.

  17. Alexandre Grigoriev says:


    HTML help UI provides many ways to open a file dialog. Use Options->Internet options (besides of the obvious View Source).

  18. Jeff Tyrrill says:

    Point taken, to those who believe I was unfairly critical of Paul.

    I don’t guarantee that systems I work on are 100% secure, and I don’t expect others to either. But there are many decisions that almost entirely move a system in the direction of being more secure (or less secure). Also, when viewed on the level of a specific vulnerability, many times it really is a binary issue–fixing the bug makes that vulnerability go away.

    I felt like making a sweeping statement in the second post akin to "we can’t be secure no matter how hard we try" had the implicit meaning "so why bother?" thus negating the very useful point that Raymond was making, which was why I responded so strongly. It felt to me like a platitude that served no positive purpose.

  19. steveg says:

    @JeffTyrill: you have servers you personally guarantee are 100% secure and will never ever ever be compromised?

    I think you’re forgetting the long history of very surprising things being hacked/compromised.

    Is that encryption you’re using secure? Really? Is the implementation secure? Prove someone hasn’t broken it, or doesn’t have a personal data centre.

    Is your OS provably secure? Pffft. Of course it isn’t — that’s why you regularly patch it.

    Is the firmware in all your network devices in your network been hacked because you unknowingly bought it after a foreign security agency? Or is the device insecure (I have a friend who tests network device security for a living. He’s *never* found a device without security issues).

    Your hackles may have been riled, but sheesh, this is the internet, after all, what do you expect?

  20. Paul says:

    Uploading scripts and running them as SYSTEM is asinine, not just insecure.

    The point stands that if you stop the user from doing that, which you should, they will attempt to find another way in.

    How many times do we see "Update to X. A vunerability has been found in X which may allow a remote attacker to take control of your system."

    I saw that a while back in something innocuous like MSPaint and laughed a little on the inside.

    I have a really secure server at home.

    It’s midway through installing Windows 2003, it’s no longer connected to the mains and I have been known to use it as a seat. Currently it’s got my tablet docking station on it.

    I doubt any remote attacker will be able to commandeer it!

Comments are closed.

Skip to main content