IE patch bugs readers

Not quite good enough

The data-binding/object-tag patch for IE, which prevents executables being launched remotely by a script, does not protect against launching from a local file, as we reported last week.

MS has used a 'security zone' approach to deciding whether a script should or should not be allowed to launch an executable. The company has argued that this approach is adequate to protect users from malicious exploitation; but we're not entirely convinced of that. So we asked El Reg's beloved readers to give it some thought and share their impressions.

You were overwhelmingly in favor of asking MS to develop the patch further, by a margin of thirty-two to four. But before we get to a sampling of your comments, let me just say that I'm not confident in the security zone approach, especially for home users; and I don't think scripts should be allowed to launch executables without warning in any case. A simple pop-up 'dialog box' asking if the action is allowed or not, with a 'don't show this warning again' checkbox, is all I would ask. This way people who have deliberately scripted tasks can avoid the nuisance of being warned every time they run one. Most home users don't do this, so the warning would be good heads-up for them. Well, that's how I'd approach it if it were my call.

Herewith a sampling of your letters, starting with the critics:

You're not blowing anything out of proportion; there is still a vulnerability. I'd rather see it fixed properly rather than a half-baked attempt. It's the 'but-all-I-did-was...' users (that most admins have to put up with) that concern me, because they're capable of unwittingly managing anything. I know idiot-proofing's not easy, but the more you try the safer the system is, and leaving gaping holes means that someone's bound to fall in. Hmmm, they're also usually the MS home users. That is scary, isn't it?

--Audrey Smith

Ever hear of the pentium bug? Not good enough on their part because they're assuming the software will only be used in a limited number of ways. Plus they now have a PR problem - and it's not like people are predisposed to trust MS in the first place


I think this is classic M$ at their best - "Erm, oh dear, something's broken, erm quick try and fix it, erm, well this sort of works, yeah quick post it on the web, then we can worry about it later - if at all." The other thing that springs to mind is - could this be a cover for M$ being able to run certain scripts on machines that we don't know about? Not wanting to be paranoid but hey!

I think you are right in your article - they should fix the WHOLE problem, not just the front end of the problem. But then, this is Micro$oft.....

--Adam Collett

The way I see it this "patch" is merely just another of M$'s "slap a band aid on it and maybe they'll (the media) will leave us alone" solutions. There is no way possible to make to big of a deal out of the security flaws M$ has forced us, the general consumer's, throat. Lucky me, the only dsl in my area is MSN, so not only do I have to protect myself from the OS (that I paid for) but I also get Outlook thrust upon me for regular email, huge amounts of spam consisting mostly of system-threatening html. All at no "extra charge".

While I don't work in the computer field. I've picked up enough to figure out how to shut down most crap, IE, M$N explorer, and that little slice of hell know as Messenger. Make too big of a deal about sloppy MS code? Not possible. Drag it all out, shove it into Billg's face and force them to "put up, or shut the fuck up".

Kudos the the folks who point out the problems after M$ fails to resolve the issue.

--Mark Orr

I rarely write to journalists, but this one has my dander up! I find MS's attitude somewhat hard to defend. Of course, I am pleased they are issuing patches. But isn't it sad just how many patches there are? End users especially must be getting patch fatigue - after all one security bulletin looks so much like the next (and they are so frequent).

You are right to call MS to account for this latest patch. MS want us to believe they are trustworthy - yet they suggest that if the security patch fails to do it's proper job, it's an issue with our expectations rather than their problem.


I'd use a stronger word, denoting the anal excretions of a male cow, but yours is a family web site and such strong language, while fair comment may not be appropriate for your site. If anything, MS should be setting our expectations by clearly saying what the patch does and what it does NOT do. To be fair, they succeed in the former, but dismally fail in the latter.

Is this really an 'innovative' company, or one run by weasel-word lawyers?

--name withheld on request

Fix the obvious symptoms and pay complete disregard to the underlying problem. Nice to know Bill and his The New Security Concious Microsoft wasn't just a load of baloney after all!


I think you are right on with your concerns. We need people like you to check behind M$, and keep us informed. I think that downloading a Web page via email or other means is a common event; therefore, a fix covering this scenario is definitely needed.

--Buck Pentecost

[That about covers the gist of it. We'll just skip the remaining twenty-five or so.]

As it doesn't seem possible to provide any parameters to the program (I've tried) this flaw seems to me to be a bit of a non-issue. A "malicious" Web site can launch calc.exe - big deal!


[later memo] On second thoughts, it might be possible to script something that repeatedly loads a known executable until the machine runs out of memory.

Microsoft's security model relies on zones. If you load a file from your local hard disk, it is considered trusted data and is allowed to more than a remote Web page. Once a user understands this concept, I think their fix for this issue makes sense. If you consider things like CD ROMs with Web pages on them, their approach gives more power and flexibility, too.

I may not like M$, but I agree with them on this one.


Why don't we just ask them to issue a patch that restricts the ability to launch any .exe, .com, .bat, .asx, etc. file at any time form any environment. It would do wonders for security and stability of the system.

--Robert Saylor, P.E., MCSE

Basically, you should be allowed to load components off of your local hard drive or Intranet, but... it should be dependant of your security settings, and it is.

The default is to allow for components to be run, but my point here is that calc.exe is no component, and that IE should check that the codebase referred to actually implements the component and the GUID it claims to have before executing it. Proper signing and certificates should furthermore be OK to run the component, and if a site admin has chosen only to allow for certain components to run that must be abided as well.

Now, all of this is a bit complicated, and I think that the best solution is that unsigned and untrusted (with positive acknowledgement from the user) execution should not be allowed in the default behaviour of IE.... so I guess that I agree with you - there's still something rotten in IE (not just in Denmark...

See... I actually changed my opinion during the writing of this e-mail, but I still think that the defaults for IE must be updated so YOU have to change the settings back to allow unsigned code to run off of your local zone.

--Dan Kalnæs,

The scenario you present in which the bug in question could still be a threat sounds rather Darwinian to me. While MS deserves criticism for their insecure and flawed products, they haved done an adequate job correcting this one and should move on to other more serious problems. Stupid people should always be given every opportunity to harm themselves. Who knows, a few more security issues like this one and maybe we'll be able to get all those AOL users off the net due to fear.

--not signed

Sponsored: Minds Mastering Machines - Call for papers now open

Biting the hand that feeds IT © 1998–2018