IE August Cumulative Security Update Now Available


The IE Cumulative Security Update for August 2010 is now available via Windows Update. This security update resolves six privately reported vulnerabilities in Internet Explorer. The most severe vulnerabilities could allow remote code execution if a user views a specially crafted Web page using Internet Explorer. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

This security update is rated Critical for Internet Explorer 6, Internet Explorer 7, and Internet Explorer 8. The security update addresses the vulnerabilities by modifying the way that Internet Explorer enforces security checks and handles objects in memory. For more information about the vulnerabilities, please see the full bulletin.

The majority of customers have automatic updating enabled and will not need to take any action because this security update will be downloaded and installed automatically. Customers who have not enabled automatic updating need to check for updates and install this update manually. For information about specific configuration options in automatic updating, see Microsoft Knowledge Base Article 294871.

For administrators and enterprise installations, or end users who want to install this security update manually, Microsoft recommends that customers apply the update immediately using update management software, or by checking for updates using the Microsoft Update service.

Tyson Storey
Program Manager

Comments (28)

  1. MS User says:

    KB2183461 is broken my Silverlight plugin for IE8. I cannot play videos using sliver light player on IE8

  2. GhastlyGibbon says:

    And for the first time, no update for IE5. ;-D

  3. Jonas Klose says:

    You diddn't mention IE9!? The dlls in IE9 were those of IE5-IE8 or am I wrong? If I'm running IE9 with the IE8 engine, could I infect my system on a site that targets these vulnerabilities in <=IE8?

  4. Jones111 says:

    You diddn't mention IE9!? The dlls in IE9 were those of IE5-IE8 or am I wrong? If I'm running IE9 with the IE8 engine, could I infect my system on a site that targets these vulnerabilities in <=IE8?

  5. EricLaw [MSFT] says:

    @Jones111: "IE9" is not yet released. If you're referring to the Platform Preview Build for IE9, then yes, some of its DLLs are from what will become IE9, while some of them are placeholders from IE8 (e.g. WinINET.dll).

    Your desktop browser (e.g. IE8) will not use the DLLs from the Platform Preview Build.  The platform preview build is used by web developers and enthusiasts to test their own sites and demos like those at http://www.ietestdrive.com.

    Platform Preview Builds should not be used as your daily browser for many reasons, including security. The PPB does not include important security features like Protected Mode, the SmartScreen Filter, the XSS Filter, and other security features present in full browsers like IE8.

  6. ieblog says:

    Corrected the bulletin links in this post.  Thanks!

  7. Fiery Kitsune says:

    Eric, does Microsoft simply not care about web experiences of the Firefox-dominated Europe?

    Everyone (Windows XP, Mac OS X, Linux) can use use WebGL yet you seek to limit Vista and Seven customers to Direct2D.

  8. BoredWithTrolls says:

    Firefox runs on Windows Vista and Windows 7, moron. Not that WebGL is really used.

  9. Feets says:

    @MS User. I'd like to understand a little more. It it all sites? Just videos? What behavior do you see? If you try the Silverlight Showcase at http://www.silverlight.net/showcase does it render as expected? What version of Windows are you running and did you install all the security fixes released yesterday?

    Thanks!

  10. Sorry, it's me again says:

    @BoredWithTrolls and all fanboys, like i said on the other thread, if Microsoft'll support WebGL, which i'm pretty sure it will, WHAT WILL YOU SAY? That WebGL is the greatest thing since sliced bread? That, haha, IE is 60 FPS faster then firefox with WebGL, meaning firefox is chop liver?

    this is a serious question! please don't look at MS before you answer :-)

    [I get the feeling that 5 or so years of hearing IE is pretty lame got to you. BTW its not that it was lame, just had poor support for standards and a lot of unnecessary. And this guy is not a troll, he is asking MS to support an open standard. Oh, and on the way, wishing DirectX dead dead dead :-) sorry got carried away]

    -MENI

  11. Harold says:

    I have a personal test suite page that tests dozens of known IE bugs with JavaScript/DOM manipulation.  I'm glad to see in the preview that many of them are now starting to get fixed (e.g. event listeners) however there are still many JavaScript bugs in IE9 platform preview 4 that have existed since IE6, are well documented, yet unaddressed.

    I'm very grateful that IE9 is now finally implementing HTML5, Canvas and SVG (and has massively improved JS performance by tapping into the GPU) but it doesn't look like much of the old JS bugs have been addressed.

    Should we be expecting improvements in these bugs being fixed in the next platform preview?

  12. EricLaw [MSFT] says:

    @Harold: Have you filed bugs from your "personal test suite" on Connect?

  13. Harold says:

    @EricLaw – my tests have been accumulated from various sources of well documented bugs over the past 5 years  (nothing that developers are unaware of).  they may be in connect (I don't know).

  14. Jack says:

    I don't know any of Harold's test cases but the most annoying issue still plaguing IE9 is the issues with access methods to elements by name/id and invalid members in those collections.

    e.g.

    the document.anchors collection contains invalid members

    and using document.getElementsByName('name'); returns totally invalid members

    Please don't be shipping IE9 touting "web standards" until these kind of glaring bugs have been rectified.

  15. hAl says:

    @Harold

    It is ridiculous to claim there are a lot of errors in IE9 here but not list any of them in any of your post nor submit them to connect.

    Provide testcases at least of things that you claim are still not solved. Them we can see if those issues are already submitted fro IE9 and the IE team can react properly.

  16. Leon says:

    @hAl what is wrong with @Harold's comments? we all have test files or even complete test beds we've built over the last dozen years.  The reality is that other than specific fixes in IE9 for un-implemented JS / DOM methods and CSS features there hasn't been many fixes to long standing IE bugs.  Setting the .innerHTML on many elements still fails horribly in IE (I appreciate that the length of the options collection for a select list is now updated correctly in IE9 when it fails to add any of the options (and wipes out the existing options) but that's a theoretical technical improvement at best.

    As for filing bugs in connect? I gave up on that when bugs constantly got ignored, set to "closed (by design)" with no indication of when they would be revived, and the total lack of a decent system to track the bugs, and the many, many default responses of "we can't reproduce the well detailed bug report you filed that several other connect users indicated they could reproduce"

    We have day jobs too.  We're sick and tired of our bug reports being put on the back burner and never given a proper response.

    When on earth are the innerHTML bugs going to be fixed? they've been broken since .innerHTML existed (BUT ONLY IN IE!) no other browsers have the same issues that IE suffers from!

    These were reported at least as early as the IE6 RTM timeframe (by my count, in 12 days that will have been 9 (NINE!!!!!) years ago!!!!)

    They were NOT fixed in IE7

    They were NOT fixed in IE8

    They ARE STILL NOT fixed in IE9!!!!

    Don't get me wrong – if MSFT promises to actually FIX the .innerHTML bugs in IE9 I will file as many bugs as they want in Connect – but little piggies will be flying sky high before I ever use Connect again unless there is a commitment from MSFT to actually fix the bugs (or provide a concrete target as to when they expect to be delivered) – I'm not wasting my time filing bugs otherwise – these bugs aren't new… as noted going on NINE years now!

    Congratulations on your ostrich impersonations! ;-)

  17. Mmmhmmm says:

    Leon: If your "connect" bug reports are as detail-free and non-credible as your rant here, it's pretty obvious to all about why your bugs got ignored.

    Whining in the comments on the blog may make you feel a little better, but it's ultimately a very selfish act that wastes everyone else's time.

  18. Leon says:

    @Mmmhmmm – I'm sorry we're you asleep for the past decade? it is common knowledge to every web developer that IE does not support setting .innerHTML on many elements.

    Internet Explorer 6, 7, 8, & 9 all fail to set the .innerHTML on the following elements:

    HTML element

    TABLE element

    TR element

    TBODY element

    THEAD element

    TFOOT element

    SELECT element

    PRE element (where the content contains linebreaks)

    any EMPTY element with overflow set to auto (where the content contains breaks)

    On the contrary, all other browsers have had no issue implementing this correctly – it works fine in Chrome, Firefox, Safari, Konqueror, SeaMonkey, Opera, Flock, Arora, Camino, K-Meleon, OmniWeb, iCab, Galeon, Epiphany, Chromium… even deprecated versions of Netscape handle it fine!

    So am I ranting? you bet I am! – and as noted I have no intention of filing these 9 bugs unless MSFT is going to step up to the plate and commit to fixing them! (they failed to do so in the last 9 years that they have been known and tracked)

  19. hAl says:

    @Leon

    Trashing some bug on an arbitrary bugsite and not even have the decency to palce a link to those bugs on the site makes the critisism opf little value. I have been on several of those site in the past finding many issues with those so called bugtests.

    If anyone caliming issues is not wiliing to put up any evidence of those issues you claim I have little faith in the issues really exisiting or being of any signifcance because they might test extremly rare occurence you will never find in the real world.

  20. Leon says:

    @hAI I'm not sure what bug site you want me to point to but these are all very easy to test and all very easy to reproduce by anyone.

    Create a Table or a Select element and try to set the .innerHTML to add table rows or select options – it just fails (and wipes out any content you had, even if you try to concatinate with "+=".

    Google for IE innerhtml bugs points to the following:

    IE fails to set the innerHTML on the SELECT object

    support.microsoft.com/…/276228

    Filed in 2003 (7 years ago)

    IE Pre/Textarea whitespace/linebreak issues:

    http://www.quirksmode.org/…/innerhtml_and_t.html

    IE Table (and related) element bugs:

    webbugtrack.blogspot.com/…/bug-210-no-innerhtml-support-on-tables.html

    that last report even includes a link to Eric Vasilik's old blog where he (@MSFT at the time) indicated some responsibility for the bug (due to building a sub-par HTML parser) whereby the bugs have existed since 1996!!!!! 14 years ago! – just how long does it take to get a fix for this?

    As I stated, twice… THIS IS NOT NEWS! these are well known major bugs that have not been fixed.

    All the msfanboys can whine all they want that I should really file these in connect but I assure you they were in Connect for the IE7 beta, ditto for IE8, ditto for IE9 – filing the bug doesn't fix it – only MSFT can fix it – and we've been waiting almost a decade now – I think it is about time for an ETA for the fix.

  21. hAl says:

    @Leon

    InnerHTML is not part of any webstandard.

    InnnerHTML is actually a proprietary Internet Explorer extension of Javascript that some other browser builders have then embraced and further extented.

    Unlike W3C DOM which is actually a W3C webstandard and which can achieve the same results as InnerHTML (though not always as easy).

    Thus there is no requirement for IE9 to support innerHTML on any of the elements you suggest.

    You are asking for IE to use other browsers proprietary extensions on IE's own proprietary extensions. That is just ridiculous.

    Those are thus not bugs anyways. It is behaving as Microsoft actually created it.

  22. steve says:

    Ha ha ha ha ha! very nice @hAl – claiming they are not bugs because IE's original implementation was broken in several areas is a very, very weak argument.

    As a developer you see this access property called "inner" "HTML" that gives you access to get/set the HTML on elements, all elements… it is only when you read the fine print on Microsoft's dev pages that you see they've conveniently added getters for everything, but setters only on most elements calling the remaining "read-only" due to internal bugs.

    Lets call a spade a spade – it is a bug, it is ugly, and it needs fixing.

  23. Spade says:

    I love this! :-)))

    …so somebody (Microsoft in this case) invents something new, which is then copied by other browser vendors. It is no standard, but an extension to a standard, and the implementation of the other browser vendors is buggy, because it is not EXACTLY the same, as the implementation of the original inventor. Now the fanboys of the minority browsers want the ORIGINAL inventor to change their invention after the buggy fashion of the minority browsers. You've really got to love this! :-)))

    Right out of the textbook of the fundamentalist anti-microsoft taliban!

    Ace of Spades

  24. Not a spade says:

    @Spade – check up your specs dude:

    dev.w3.org/…/Overview.html

    HTML5 has a getter/setter:

    interface HTMLElement : Element {

       // dynamic markup insertion

      attribute DOMString innerHTML;

      attribute DOMString outerHTML;

      …

    }

    If IE plans to be HTML5 compatible – it had better get its darn parser bugs sorted out!

    IE's implementation (even if it is just as they shipped it) is broken.  Claiming crud about "we invented it to only work on some elements" is a load of junk.  They wanted it to work on everything but had to limit their implementation due to other bugs in their core DOM parsing engine.

    Rather than fix the engine (the obvious choice) they decided to let it slide and make the setter invalid on certain elements (*cough*, *cough*, "readonly")

    .innerHTML was a proprietary extension when IE added it but once other vendors incorporated it – completely of course because they don't have the DOM bugs IE has – it became ubiquitous.

    Long story short – Microsoft needs to clean up this mess ASAP – otherwise this "universal markup" thing won't fly because IE is holding back the web again.

    All this junk about "MSFT invented it to be broken" is garbage…. think about cars… someone had to be first to invent the seatbelt (VOLVO)… later on others copied it… it became standard.  If  VOLVO starts claiming that they won't install seatbelts in the back seat of cars because they can't find suitable anchor points in their design, no one would accept this (whether they invented it or not).

    All you ms-fanboys get off your high horses – you want these bugs fixed as much as we do – occasionally you have to just accept that Microsoft isn't perfect – but they can always fix or improve their software (that's how software works, it evolves)

    Lets not fight over who invented it first, lets just get together and get it fixed in IE!

  25. Tired of trolls says:

    "notaspade" — yes, this is only one of many cases where the standards bodies (aka a de-facto cartel of Microsoft's competitors) have copied something out of IE (FavIcons, anyone?) and changed the spec just enough so that the inventor's application doesn't meet the "standard."

    Leon — if you want to whine, go over to Mozilla's bug database and look at how many bugs have NEVER even been looked at. Watch the collective incompetence as there are 8 year old debates about whether or not OnChange should fire when the contents of a SELECT control CHANGE via the keyboard rather than the mouse. And so on. Any non-trivial engineering undertaking (aka virtually all software) has a nearly infinite number of issues. The trick between being a successful, commonly used software product (e.g. IE) vs. a niche product with ardent  fans (e.g. Opera) is being smart about which issues you choose to address.

    Now, on the other hand– the lack of a spell-checker in IE? That's just stupid.

  26. Klaus says:

    just for the record the msdn documentation on innerHTML does not mention the "select" element in its list of "read-only" elements that innerHTML does not work on yet does include it in the list of elements that support it (at the end of the page)

    msdn.microsoft.com/…/ms533897.aspx

    just wondering – by any chance does it work on the "optgroup" element?

    as for the argument on whether this is a bug or not (it most certainly is – those barking that the documentation states it isn't a bug are discredited with the above discrepancy and the blog post that does indicate that there is a an underlying bug in the IE Trident DOM parser)…. but while we are at it can we bring up the return value? yikes! that is not the innerHTML that was set and content that was set in a valid well-formed format is returned in a mish mash of invalid tags regardless of the doctype specified.

    If we are voting – I don't mind the getter not being fixed but it is about time that the setter was fixed it has been broken long enough thanks.

  27. tony says:

    There is a lot of discussion about the innerHTML bugs in IE above here (and across the Internet) but it has been very quiet from Microsoft?!

    Should we take silence as a good sign that you are busy working on the fixes for this? or that you are hoping to try and sweep this under the rug as soon as it quiets back down a bit?