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
Anonymous
August 10, 2010
the bulletin link should be www.microsoft.com/.../MS10-053.mspxAnonymous
August 10, 2010
KB2183461 is broken my Silverlight plugin for IE8. I cannot play videos using sliver light player on IE8Anonymous
August 10, 2010
And for the first time, no update for IE5. ;-DAnonymous
August 11, 2010
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?Anonymous
August 11, 2010
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?Anonymous
August 11, 2010
@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 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.Anonymous
August 11, 2010
Corrected the bulletin links in this post. Thanks!Anonymous
August 11, 2010
The comment has been removedAnonymous
August 11, 2010
Firefox runs on Windows Vista and Windows 7, moron. Not that WebGL is really used.Anonymous
August 11, 2010
@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 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!Anonymous
August 11, 2010
The comment has been removedAnonymous
August 11, 2010
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?Anonymous
August 11, 2010
@Harold: Have you filed bugs from your "personal test suite" on Connect?Anonymous
August 12, 2010
@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).Anonymous
August 12, 2010
The comment has been removedAnonymous
August 12, 2010
@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.Anonymous
August 15, 2010
The comment has been removedAnonymous
August 15, 2010
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.Anonymous
August 15, 2010
@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)Anonymous
August 15, 2010
@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.Anonymous
August 15, 2010
@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: 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.Anonymous
August 15, 2010
@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.Anonymous
August 15, 2010
The comment has been removedAnonymous
August 15, 2010
The comment has been removedAnonymous
August 15, 2010
The comment has been removedAnonymous
August 15, 2010
The comment has been removedAnonymous
August 16, 2010
The comment has been removedAnonymous
August 17, 2010
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?