Internet Explorer virus used to attack US nuclear weapons researchers

Internet Explorer virus used to attack US nuclear weapons

By Dark Politricks

From the popular alternative news site darkpolitricks.com comes the news that the "most popular browser in the USA - yes IE 8!" has been used by hackers to infiltrate US nuclear weapon researchers computers in America.

Apparently zero day exploits were used, as well as a virus on a popular website frequented by members of the nuclear weapons industry.

The hack was only discovered after an unknown number of computers became infected with a backdoor Trojan that was reportedly installed on the machines of web surfers who used IE 8 to navigate to a specific page on the US Department of Labor website.

"The Department of Labor site was rigged to redirect users to another site that infected computers with an iteration of the infamous "Poison Ivy" Trojan, which was able to avoid detection by all but two major anti-virus products,” Ben Weitzenkorn wrote Monday for TechNews Daily."

According to Microsoft, "The vulnerability may corrupt memory in a way that could allow an attacker to execute arbitrary code in the context of the current user within Internet Explorer."

Why IE 8 is still the most popular browser in the USA I have no idea. Have they not heard of Chrome, FireFox or even IE 9?

We all know IE 6 was a danger to itself, it's users and everyone else around it.

This was due to the severe amount of security holes in the code and the large number of hacks that had to be used to make websites work in it. This was both by CSS designers and JavaScript developers who had to come up with the many frameworks we are now left with. All just to make a standards compliant webpage work in IE and normal browsers.

Just think if it wasn't for IE 5 and IE 6 we probably would have never even heard of jQuery, Prototype, addEvent functions and hacks to get uncommon browsers working on your PC like window.opera and user-agents that are so full of shit they have lost all meaning to anyone.

You can view the full article US nuclear weapons researchers targeted with Internet Explorer virus at the popular #altnews site darkpolitricks.com.

Why I hate debugging in Internet Explorer 8

Debugging Javascript in Internet Explorer

Now with IE 8 and it's new developer toolbar debugging Javascript should have become a lot easier. There is now no need to load up Firebug Lite to get a console or use bookmarklets to inspect the DOM or view the generated source and in theory this is all well and good.

However in practise I have found IE 8 to be so unusable that I have literally stopped using it during development unless I really have to.

When I do find myself having to test some code to ensure it works in IE I have to make a little prayer to the God of Geekdom before opening it up because I know that within the next 5 minutes I will have found myself killing the IE process within Task Manager a couple of times at the very least.

Not only does IE 8 consume a large portion of all my CPU cycles it's very ill thought out event model makes debugging any kind of DOM manipulation a very slow painful chore.

Unlike proper browsers IE's event model is single threaded which means that only one event can occur at any point in time during a pages lifetime. This is why IE has the window.event object as it holds the current event being processed at any point in time.

Many developers over the years have moaned at IE for this and have hoped that with each new release of an IE browser that they would fix this odd behaviour. However every time a new version is rolled out a lot of web developers are always bitterly disappointed because apparently Microsoft feels this quirky event model is a design feature to be enjoyed rather than a bug to be suffered and they don't seem to have any intention whatsoever of fixing it or making it DOM 2 compliant at the least.

I don't know why they cannot do what Opera does and just implement both event models. At least that way they can make all the proper web developers happy at the same time as all the sado masochists who enjoy IE development

This event model really comes into its own when you are trying to debug something using the new developer toolbar as very often you want to pipe debug messages to the console.

If you are just outputting the odd message whenever a button is clicked or form loaded then this can be okay but if you attempt to do anything that involves fast moving events such as moving elements around the page or tracking fast incrementing counters then you will soon suffer the pain that comes with waiting many minutes for the console to catch up with the browsers action.

Whereas other browsers such as Chrome or Firefox are perfectly capable of outputting lots of debug messages to the console at the same time as mousemove events are being fired IE seems to either batch them all up and spit them out when the CPU drops below 50% (which might be never) or occasionally the whole browser will just crash.

At first I thought it was just me as my work PC is not the fastest machine in the office but I have seen this problem on many other peoples computers and I have also experienced it at home on my Sony VAIO laptop.

As a test I have created the following page which can be found here:

www.strictly-software.com/debug_test.htm

Try it out for yourself in a couple of browsers including IE 8 and see what you think. I haven't had the chance to test IE 9 yet so I don't know if the problem is the same with that version but I would be interested to know if anyone could test this for me.

The test is simple and just includes a mousemove event which collects the current mouse co-ordinates and pipes them to the console. It does this for a number of iterations which can be set with the input box.

I have found that IE will manage when setting this counter to anything less than 100 but putting it to 1000 or above it just crashes or freezes my own browser as well as killing the CPU.

Let me know what you think of this test and whether anyone else has major issues with IE and it's console logging capabilities.

Visit the test page here: www.strictly-software.com/debug_test.htm

Firebug So So Slow

Developer Toolbars Slowing Sites Down

Following on from my whinge the other day about how IE 8.0's developer toolbar is causing pages to hang, CPU to max out (50% on dual core). I have noticed on a few sites now since upgrading to Firefox 3.5.2 and Firebug 1.4.2 that I have similar problems.

I have just been to my football site www.hattrickheaven.com and was clicking some of the leagues down the sidebars and wondering why the pages were taking so long to load. I then went to Chrome and tried the same links and the pages loaded as fast as lightening. This made me wonder about Firebug and low and behold disabling Firebug stopped the delay and the pages loaded very quickly. I would like some other people to try the same thing if they have Firebug and let me know the results e.g try these links with Firebug enabled and with it disabled:

http://www.hattrickheaven.com/leagues/en/England

http://www.hattrickheaven.com/leagues/en/Brazil

With Firebug disabled they should load pretty quickly however with Firebug enabled its taking anything up to 15 seconds! Also check the Task Manager and see what CPU level Firefox shows as mine shows 50%.

I don't know if this is something to do with something within my page that Firebug cannot handle but the only validation errors I have are missing ALT attributes.

So as a tip for slow loading sites I would suggest in both IE and Firefox disabling the developer toolbar and Firebug and seeing if that helps speed up the load times. It seems to have worked for a number of sites now which is a shame as both toolbars should be great add-ons if only they could work without slowing everything down.

Problems with IE 8 Developer Toolbar

IE 8 Developer Toolbar Hanging and Locking Browser

Update 25-Sep-09

I have found that one of the primary causes of IE 8 hanging with the developer toolbar is its console logger. If you have a script that outputs messages to the console I have found that IE will hang until all the messages have been outputted to the console. The more messages you have the longer it takes. Also unlike Firebug which seems to output the messages during normal page load activity IE seems to cache all the messages and then output them all in one batch (or has the appearance of doing so). The CPU seems to max out during the outputting of these messages.

I have been doing a lot of work lately with styles, fades and CSS which has obviously meant working with Internet Explorer building in code to handle the differences between IE and other browsers e.g getting computed styles from IEs currentStyle, Opacity differences etc. This has meant using trying to use the Developer Toolbar which was shipped as standard in IE 8.

It should be a great add-on as it lets you do all the things Firebug has allowed developers to do for a long while including switching Javascript on/off, clearing sessions and cookies, viewing the DOM, inspecting elements and their styles and the ability to output debug to the console.

However I have found that this developer toolbar add-on has a tendency to hang especially after the first use of it. I can go to a page and then open the developer window to change the browser or document modes or step through some debug. However if I minimise the window and go back to the main window and then try to open the developer window again the majority of the time it will refuse to come back to focus. Even if I try to maximise or restore the window or go to the desktop to find it. I have also noticed that when I do get focus back it will only partially be visible as if its trying to load content but struggling.

In fact checking the Task Manager usually reveals a CPU of 50% or more. There will be two processes open one for the developer window the other for the main IE window but even though the developer window is hanging it seems the process with the high CPU is the browser window.

I first thought it may just be some heavy Javascript code running on the page but I have had this problem with numerous sites and other people in the office have had similar issues.

I don't know if this is common issue that developers have found but at the moment I am tending to use Firebug-lite or a custom DIV for outputting debug if I need to and custom pages for killing sessions and checking the current document mode and browser mode which are the 3 most common tasks I find myself doing which is a shame as I really like the layout and functionality the toolbar offers. Its just a shame that it seems to run very badly at the moment.

Problems Upgrading to IE 8

Upgrading to Internet Explorer 8.0

There are plenty of sites already out there listing all the many bugs or "features" that IE 8 has brought to the table but so far the two main ones I have come across are:


Problems when FirebugLite is also running in IE 8.

I was getting a "Function Expected" error on line 1499 in the IsArray function. As a workaround I added the following line as the first line in the function e.g

IsArray:function(_object){
if(!_object) return false;

This prevents the error but the Firebug-lite console does not display correctly in IE 8 when the document mode is also IE 8. To get round this I set the document mode to IE 7 and then it works fine.

Remember IE 8 now has a console in the developer tools options for outputting custom debug messages plus its now got a great debugger tool with all the same features as Firebug so Firebug-Lite isn't really needed anymore. However it should still be possible to run the two side by side.


Issue with clip and rect function

I also found an "invalid argument" error when setting the clip properties using the rect function. The code was for a scroller and the original version that raised the error was:

this.canvas.style.clip = "rect(0 " + this.canvasWidth + " " + this.canvasHeight + " 0)";

The fix was to add "px" after the dimension values and separate the values with commas e.g

this.canvas.style.clip = "rect(0px, " + parseInt(this.canvasWidth) + "px, " + parseInt(this.canvasHeight) + "px, 0px)";

I have come across a few errors such as "null is null or not an object" (you don't say!) which have been simple fixes and have just required testing the values correctly before using them.

I am sure there are hundreds more errors and that many many hours will be devoted to fixing them all in a similar manner to the last 2 major releases of IE. However overall I am very happy that they seem to have caught up with Firefox and the others and have implemented a pretty decent developer tools section including a great debugger that actually gives you a useful error message for once. Plus I like the fact that the GUI hasn't changed very much in the way that IE 6 to IE 7 did and I do like the little touches like the accelerators.

However its a shame that with such a major release they couldn't have gone the whole hog and sorted their Javascript engine out to make that standards compliant as well as the CSS. Apparently they have rewritten the whole JS engine so now was as good a time as any to bite the bullet and do it and they would have made the whole web development community very happy if they had done so. Even with the rewrite their event model is still pretty shoddy and even if they wanted to keep with their intermediary event model (attachEvent, removeEvent, returnValue, srcElement etc) then they could have fixed those annoying little issues that people have spent thousands of development hours resolving such as the this keyword referring to the window and not the object in question and attaching event listeners in order rather than randomly.

It seems pretty likely that more and more companies will get to the point where developing for IE becomes too much work and stop supporting it. Market share of Firefox, Chrome, Safari and Opera are increasing all the time so it may not be that long until you find a lot of sites just redirecting to a Mozilla download page when you access their site in IE. If that does happen then it might be a shame to some people but Microsoft will only have themselves to blame and may find that they have missed a great opportunity with this release to prevent that from occurring.

IE 8 Document and Browser modes

Controlling IE 8 Browser and Document Modes

In Internet Explorer 8 the developer toolbar can control the following settings and will override any other settings that have been set e.g META tags or the Compatibility View options. On changing a setting the browser will refresh and load the appropriate new configuration.

I will list out the various document and browser modes with the basic differences but if you are in a hurry and just require a Javascript function that you can use to determine the clients current IE8 settings then that link will sort that for you. For an explanation on browser compatibility mode testing then this link will give you an article explaining the combination of agent sniffing and object detection that is required for identifying a clients IE8 browser settings.

Browser Modes:

Internet Explorer 8 Mode

The browser will run as IE 8.0 and the user-agent will appear as an IE 8.0 user-agent e.g

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB5; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 1.1.4322; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)

Notice the mention of Trident/4.0 which is the name and version of the rendering engine.

A new Javascript engine is used in IE 8.0 so there will be numerous differences for example using getElementById to return an element by name will not work anymore which is the correct way of doing things however if you didn't know this and did use it in IE to access elements you will experience errors when running in full IE 8 mode.

Internet Explorer 7 Mode

The browser will run as if it were actually IE 7.0 and the user-agent will appear as an IE 7.0 user-agent e.g:

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; GTB5; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 1.1.4322; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)

Javascript will run as it does in IE 7.0 for example using getElementById to return an element by name will work.

Internet Explorer 8 Compatibility Mode

This mode means that, and I quote from ieblog

"In a nutshell, Compatibility View allows content designed for older web browsers to still work well in Internet Explorer 8."

So in all respects the browser is still running as IE 8.0 but allows sites that worked perfectly well in IE 7.0 to continue to work correctly without having to revert to IE 7.0 mode.

By default IE will set all publicly accessible Internet sites to run in IE 8 mode and all Intranet sites to IE 8 compat mode.

For Internet sites it comes across which it feels should run in compatibility mode such as those with strict doctypes then it will display a button to the user to allow them to change to compatibility mode. For sites that are using quirks mode it will not offer this option so do not expect the button to appear all the time.

The user-agent in IE 8 Compatibility Mode is displayed similarly to IE 8 but with a 7 e.g

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; GTB5; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 1.1.4322; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)

Javascript should run as it did in IE 7 for example using getElementById to return an element by name will work.

Document Modes:

Quirks Mode (e.g IE 5)

This document mode setting will render pages as if there was no doctype specified. This will be the same as if you were using older IE versions such as IE 5.0.

Internet Explorer 7 Standards Mode

This document mode will render pages as they would be displayed in IE 7.0 when a strict doctype was specified.

Internet Explorer 8 Standards Mode (Page Default)

This document mode will render pages in the new IE 8 standards compliant manner. IE 8 apparently adheres to the CSS 2.1 specification and there are numerous changes to be aware of. For instance there is no longer any support for CSS expressions.

For a list of the various changes and potential problems that IE 8 will bring to your development view the following article: http://blogs.msdn.com/ie/archive/2009/03/12/site-compatibility-and-ie8.aspx


How to detect which settings are enabled

If for whatever reason you need to detect client side which of these various settings the user currently has enabled in their browser then you can use a combination of user-agent sniffing and object detection to work out the true browser version and rendering engine. See the following article about how to detect the settings using Javascript.

The new META UA-Compatible tag

Another new feature in IE 8 is the ability to quickly fix any potential problems that all these new document and browser modes may bring by adding a META tag to your existing sites. To force a page to run in IE 8 standards mode we can add the following META tag to pages:

<meta http-equiv="X-UA-Compatible" content="IE=8">

Or if you find that your sites do not currently work in IE 8.0 standards mode you can force them to work as they did in IE 7.0 with the following META tag:

<meta http-equiv="X-UA-Compatible" content="IE=7">

Once you get your site up to scratch you can remove the tags.