Home > Security > Some versions of Opera vulnerable to "JavaScript Ghost bug”

Some versions of Opera vulnerable to "JavaScript Ghost bug”

June 8, 2005

Opera 7.54 running XP SP2 and Opera 8.0 running XP are both vulnerable to the “JavaScript Ghost bug”. Internet Explorer (IE) is also vulnerable to this bug.

The bug, discovered by Pascal Vyncke, makes it possible to run a JavaScript function on the computer of the surfer, but the source code of the JavaScript cannot be seen by the surfer and is also “forgotten” by browser.

Usually the html code and the JavaScript of all webpages can be seen in the browser (in Opera: View > Source or CTR + F3); with this bug, however, you can’t even view the source code (it disappears like a ghost).

Click here to see the demo of the exploit for the JavaScript Ghost bug.

If your browser is vulnerable to this bug, then you will only see “The time is now xxx”, where xxx is the date and time. You will not see the “Something before the JavaScript” and also not the “and something after the JavaScript”.

More info

Update (6/9/2005): After further looking into this “bug”, it appears to be that it’s NOT a security vulnerability. In fact, one Opera developer even told me that not only is there no security problem but that they won’t even fix it. “The statements about this behavior enabling hackers to run abusive JavaScripts or get such JavaScripts past internet security software appear to be pure fantasy on the author’s part.”

SeniorenNet, which reported this bug information, updated their advisory to include the fact there is no security vulnerability in Opera.

Categories: Security
  1. Anonymous
    June 8, 2005 at 9:03 pm

    Urg. That’s one more thing for Opera to worry about as 8.01 gets delayed. I hope they can get it fixed in 8.01 since an unresolved security issue is worse than the bugs they were fiddling with.

    Maybe the delay of 8.01 can be a blessing in disguise if it keeps them from having to put out an 8.02 ^_^

  2. June 8, 2005 at 11:16 pm

    OK … help to understand, please … what is the practical vulnerability here. What is the practical risk? What havoc can potentially happen due to this? Thank you.

  3. June 8, 2005 at 11:29 pm

    treego14, it’s not necessarily a security vulnerability, but a bug nonetheless.

    From the security researcher who discovered the bug:
    “This bug can be used to run random JavaScript code on the user’s machine without the user even having the ability to check the JavaScript code. Software running on the computer to protect the user (like Norton, McAfee,…) that check the JavaScript code to be not harmful will not work because the original JavaScript source code will not be visible and even reloading the page, printing or saving the page will not give the original JavaScript and cannot be checked.”

    Though I’m not sure he is entirely correct on this argument, since the AntiVirus program will scan the JavaScript the first time, if it finds a problem, then it will be quarantined.

  4. June 9, 2005 at 3:18 am

    I used to use this “bug” many years ago when I already knew lots of JavaScript but was still an idiot accessibility-wise. I used to have a homepage where I (besides blocking non-IE browsers…) used exactly this method to generate the HTML. (One of the reasons was that it was a frameset; I wanted to be able to give a URL in the query string to load in one of the frames; the JavaScript did this and generated the HTML with the correct URL as the source of one of the frames).

    I used the same thing in a small JavaScript-based application too (a kind of a search base), because of the same reason. It was one document only which took query strings to show different pages. I wanted neat HTML pages generated; the source itself was a >30 kB JavaScript mess. IIRC, in IE5 (that I used at the time) File -> Save As saved the generated page and not the actual document, which was useful.

    I found the behavior very logical; I didn’t think it was a bug. 😛 After all, where should document.written text be appended when called upon an event? The same goes for any event (onmouseover, onclick, etc)

    Fortunately, (unfortunately at the time), there is a workaround in IE. You should have a “modify” button in your IE toolbar, often quite to the right. If you don’t have it, you can edit the toolbar and add the button. If you click it, it views the source of the original document (not the JavaScript generated one) in Notepad. There might be an arrow down with options too (such as MS Word or FrontPage). I remember cussing this button very loud when I found no way to disable it… yep, horrible coding memories 😀 I used location.replace to disable the back button too 😐

  5. June 9, 2005 at 7:00 am

    I don’t really see the buggy behaviour, either. What happens is that JS code is used to rewrite the page.
    In Opera actually, the original page is present in history, so hitting “Back” solves the ghost mystery. And in all browsers, running
    javascript:document.write(“The time is now: ” + Date() )
    has the same effect: an apparently empty page that has, nonetheless, content.
    As for the “AV programs can’t see it” part, it’s totally untrue. Just use Opera transfer to download the exploit_javascript_ie_6_bug.htm page and see for yourself.
    What really surprises me is that Firefox doesn’t comply with the
    instruction. Any thoughts?

  6. Anonymous
    June 9, 2005 at 8:33 am

    very simple problem. document replace in memory with data of javascript. Opera understand it as new page, but don’t see source. You can press “Back” for view source ^_^

  7. June 9, 2005 at 4:12 pm

    I have also noted this behavior many years ago. If the document.write() method is used after the page is loaded, the whole content just gets replaced by the written data. I think this is completely logical.

    Also you can note that in Opera you can click the “Back” button after the method gets executed once the original page is loaded. This means that the browser actually replaces the old page in the window with the generated one. And this means that nothing is hidden from the user. Just the location of the window is changed and the generated page has replaced the original.

  8. June 10, 2005 at 3:27 am

    “Sensationalism runs rampant at Opera fan site — blog at 11.”

    Technical summary: a script on an HTML page loaded off the net creates entirely new content using a script, thereby disguising the original contents. The HTML source of the new page cannot be viewed at all in some browsers (including Opera); and the HTML source of the original cannot easily be viewed in some others.

    The reporter claims the following vulnerabilities:

    * Can be abused by hackers to run harmful JavaScript code

    Only if “harmful javascript code” is possible in the first place. All browser vendors, including Microsoft, take this threat seriously, and are constantly watched by many security companies. “Harmful javascript code” is not so easily created any longer.

    * Can be abused to mislead existing protection against harmful JavaScript code, like software from Norton, McAfee

    This is true if you simply rot13 script content on any page, or use any other steganographic technique. “Eval” is your friend here. This new “exploit” adds nothing.

    * Can be abused to mislead the search engines Google, MSN, Yahoo, AltaVista,

    So can meta-tags and hidden content on almost any page. So can meta-refresh and redirects. So can javascript redirects. Search engines need to deal with this.

    * Unpleasant for JavaScript programmers

    Well, wget is your friend, and in Opera you can always use Delete Private Data first and then download a page, if you want to know what’s in it. The original source is there for you to read (just remember to gunzip first 🙂
    Once you have original source, few things can be kept secret.

    If there is an Opera bug here it is that View source does not work on generated page content, but calling that a security bug misses the target completely.

  1. No trackbacks yet.
Comments are closed.
%d bloggers like this: