Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Internet Explorer Security

New IE Remote Code Execution Vulnerability Discovered 63

An anonymous reader writes "Microsoft is investigating a new remote code execution vulnerability in Internet Explorer and preparing a security update for all supported versions of its browser (IE6, IE7, IE8, IE9, IE10, and IE11). The company has issued a security advisory in the meantime because it has confirmed reports that the issue is being exploited in a 'limited number of targeted attacks' specifically directed at IE8 and IE9."
This discussion has been archived. No new comments can be posted.

New IE Remote Code Execution Vulnerability Discovered

Comments Filter:
  • Which is way better than having an advisory and then having to wait weeks for a fix that requires a reboot,

    • by Anonymous Coward

      The FixIt is only for 32-bit and can't be deployed, must be installed. Fanguish.

  • by ArcadeMan ( 2766669 ) on Wednesday September 18, 2013 @10:09AM (#44883341)

    Even Microsoft sent flowers to the mock funerals [theregister.co.uk]. And now they're digging out the grave to patch a corpse?

    • by Anonymous Coward on Wednesday September 18, 2013 @10:20AM (#44883453)

      Even Microsoft sent flowers to the mock funerals [theregister.co.uk]. And now they're digging out the grave to patch a corpse?

      You can be pretty sure they would rather not have to work on it, but they've committed to supporting it until Spring 2014.

      They've made a rod for their own back with that one, but that's how it is.

      The really exciting bit will be when IE6 support finally does come to an end. I'd be willing to bet there are people who've found expoits but are holding back from using them until then. My bet is that anyone still using IE6 on the day of the last security patch will be hacked into oblivion by the end of that week.

      • by yuhong ( 1378501 )

        Actually IE6 is supported until July 2015 if you count Server 2003. And BTW IE7 is supported until January 2020 if you count Server 2008. I wonder how much it costs to support each version of IE for MS.

        • by Rayor ( 975326 )
          It even says in the very article OP cited that Microsoft said they would continue to support it.
    • It is because back in the 1990s Microsoft intermingled parts of their OS and browser and insisted their browser was "integrated" in such a way that it could not be removed.

      As everyone can clearly see now, this was a dumb thing to do. They did it purely to dissuade vendors from bundling other competing browsers. But now they are committed to supporting the OS and browser as the same piece of software.

      Had they not "integrated" the products, even if they had bundled them, they could have chosen to EOL the bro

  • by jones_supa ( 887896 ) on Wednesday September 18, 2013 @10:12AM (#44883367)
    Things like this happen, but I have to say that these days Microsoft has mostly taped Windows together quite well. We don't anymore see sensational headlines like "Blaster worm infects millions of computers". So for the 6.x core things are way better than in the past. However the EOL'ing of Windows XP will probably zombify heaps of machines.
    • by mwvdlee ( 775178 )

      Just like you didn't hear about the ~20k people that died of starvation today; it's not news if it happens every day.

    • Things like this happen, but I have to say that these days Microsoft has mostly taped Windows together quite well. We don't anymore see sensational headlines like "Blaster worm infects millions of computers"

      Hmm, well, before Snowden we didn't see any headlines like "NSA is beyond creepy, LoveINT: using PRISM spying on romantic interests?"

      I guess the spying just wasn't happening until the headlines appeared. Similarly, I guess all the unpatched exploits sitting in my
      /with/great/power/comes/great/responsibility/ directory don't exist either. I mean, it's not like I didn't inform MS about them and they just haven't patched them. I bet I'm the only person on the planet capable of discovering multiple remote

    • Great points. I've thought about the XP EOL issue as well. Unless MS changes plans somehow, is nearly all downside and not much upside. They've still got close to 40% of their user base on it - they drop the security updates and every new security update for the newer versions is just a road map on what to exploit in XP. If the users dump XP in large numbers and don't upgrade (go Linux, go Mac, go Chrome) MS looses big chunks of marketshare (further making things look worse for them).

      About the on
    • by hAckz0r ( 989977 ) on Wednesday September 18, 2013 @11:48AM (#44884435)
      That because the threat has changed. Now it's about botnets and making a long term profit, not just scaring people senseless. If the botnet is not completely stealth then it is not successful, and dies an early death. The current set of botnets are almost military grade software, out there waiting for the highest bidders line of work. The problem has not gone away, its just gone underground where only the most talented admins can even find or track them.

      .
      Botnet Command and Control map:
      https://www.shadowserver.org/wiki/pmwiki.php/Stats/BotnetMaps#botnet [shadowserver.org]

    • by hweimer ( 709734 )

      There have been reports on 58 different remote code execution vulnerabilities [nist.gov] in Internet Explorer 10 in 2013 alone. I would hardly call that "taped together quite well".

      • Chrome the favoured browser on /. had a fair share of remote execution vulnerabilities over the last year or so. I really wish MS would provide 2 versions of their IE. One of end users and one for Enterprise. The boat load of extra security features in IE = large gaps to cover in QC... Just my 2 cents. I don't really care what browser people use as long as it works with our internal applications. Currently our internal apps support all 3 major browsers. Safari is black listed due to it's known issues with A

  • The bad guys could have kept this secret till after the end-of-life for XP and made a mint.

    • I'm not sure that would have mattered. This is a browser issue, not an OS issue. TFS also states IE10 is included in the problem, which to my knowledge only runs on windows 8.
      • IE10 is available for Win7 - in fact, you need to apply an "IE10 Blocker" to keep MS Automatic Updates from forcing it down your throat.

        Granted, from my experience, IE10 on Win7 is a bit different under the hood from IE10 on Win8 - I've run into quite a few issues where there was a problem in IE10 on Win7, but it was ok on Win8 - or vice versa.

    • The bad guys could have kept this secret till after the end-of-life for XP and made a mint.

      Economics 101: That which is in increasing supply is priced lower.

      Exploits are caused by programming mistakes. In Windows there is a near boundless supply of exploit vectors, due to the quality of MS code... The only reason folks can sell Windows exploits at all is because security researchers are providing the labor to mine the exploits. Dirt is not scarce. You pay for dirt because of the labor others perform to move it about. It's the labor which is scarce, not the exploit vectors.

      The limiting fa

  • I thought IE 10 and after were sand-boxed? Or is it the nature of the buffer overrun that the injection gets CPU level access?

    According to the advisory they only get current user-level access. How do they run a buffer overrun exploit that actual stays in the user-context and doesn't go all the way to the CPU?

    • It sounds like the destruction of objects is incomplete, so the attacker can still write to that area of memory. It's certainly possible that it's writeable BECAUSE it's still associated with the process, which mean it runs in the context of that process. Additionally, it's likely that while the attacker can write to the memory, they can't arbitrarily execute it directly. Rather, they have to cause IE to execute it, in which case it would run with the privileges IE has when IE runs it.

      A security problem

      • by yuhong ( 1378501 )

        A security problem there is that since IE4, IE has been integrated with the system shell. Therefore, IE privileges are shell privileges - anything the user can do, the browser can do. For this reason, I much prefer a browser that is only a browser, not another view of the system shell. A browser that's just a browser can only screw up web pages, not the entire system.

        Huh? All process you start after log in have the same privileges as the user you are logged into.

    • You believed the bulls^H^H hype?

      I liked that Microsoft admitted IE8 and IE9 were being hit, the implication being that IE10 is perfectly ok, completely unaffected and you should upgrade, but they're still going to patch it, you know, just to be on the safe side...

    • by DarkOx ( 621550 )

      A buffer overrun does not by nature imply one can escalate privileges beyond the context of the user the process is running as.

      Most modern operating systems protect the memory region a process has been assigned to run in by the kernel. This is partially implemented with hardware support from the MMU so if the kernel has setup the hardware properly there are few ways for things to go wrong. In general a process cannot read or write to a memory region it does not own. When it tries it will be blocked and a

  • New IE Remote Code Execution Vulnerability Discovered... 3 years ago, reported to Microsoft, that reported it to the NSA, that took advantage of it all that time. Now a new, safer backdoor that only they should exploit is being deployed thru the fix for this vulnerability.

    Is all those new slashdot redesigns, headlines can't hold all the relevant information anymore.

  • If I were to guess, NSA and MS must have coded the back door themselves.
  • I think I remember using it once. But the alternative was Netscape 4.

Get hold of portable property. -- Charles Dickens, "Great Expectations"

Working...