Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Tuesday February 20 2018, @03:44PM   Printer-friendly
from the responsible-disclosure dept.

Google's Project Zero has disclosed a vulnerability in the Microsoft Edge web browser that bypasses the browser's Arbitrary Code Guard (ACG). Project Zero disclosed the bug 14 days after the end of the usual 90-day period, but it apparently wasn't enough time for Microsoft to patch it:

Google's Project Zero initiative tasks its security researchers with finding flaws in various software products developed by the company itself as well as other firms. Back in 2016, it revealed a serious vulnerability present in Windows 10, and reported a "crazy bad vulnerability" in Windows in 2017. Now, the firm has disclosed another security flaw in Microsoft Edge, after the Redmond giant failed to fix it in the allotted time.

[...] According to the Microsoft Security Response Center (MSRC), the problem turned out to be more complex than initially believed, due to which it was given an additional 14-day grace period by Google. Although the company missed this deadline in its February Patch Tuesday too - which forced Google to make the flaw public - Microsoft is confident that it will resolve the issue by March 13, aligning the shipment of the fix with the Patch Tuesday in March.

Also at The Verge and BetaNews.


Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 0) by Anonymous Coward on Tuesday February 20 2018, @03:59PM (11 children)

    by Anonymous Coward on Tuesday February 20 2018, @03:59PM (#640696)

    So, it is actually fixed, but not released yet. Why this semi-hard deadline of 90 days (with 2 weeks extension). Couldn't they just wait another few weeks for disclosing it, until the patch is actually released? Why the rush of disclosing it?

    • (Score: 5, Informative) by takyon on Tuesday February 20 2018, @04:03PM (9 children)

      by takyon (881) <takyonNO@SPAMsoylentnews.org> on Tuesday February 20 2018, @04:03PM (#640698) Journal

      https://googleprojectzero.blogspot.com/2015/02/feedback-and-data-driven-updates-to.html [blogspot.com]

      Disclosure deadlines have long been an industry standard practice. They improve end-user security by getting security patches to users faster. As noted in CERT’s 45-day disclosure policy, they also “balance the need of the public to be informed of security vulnerabilities with vendors' need for time to respond effectively”. Yahoo!’s 90-day policy notes that “Time is of the essence when we discover these types of issues: the more quickly we address the risks, the less harm an attack can cause”. ZDI’s 120-day policy notes that releasing vulnerability details can “enable the defensive community to protect the user”.

      [...] Deadlines appear to be working to improve patch times and end user security -- especially when enforced consistently.

      --
      [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
      • (Score: 0, Disagree) by Anonymous Coward on Tuesday February 20 2018, @04:15PM (8 children)

        by Anonymous Coward on Tuesday February 20 2018, @04:15PM (#640702)

        That's a nice business you got going there, be a shame if something were to happen to it...

        The embargo window is there to make sure that the vendor gets their act together and actually fixes things instead of being a black hole of bug-reports. In this case, Google acted irresponsibly because the intent of the embargo was satisfied: MSFT has been trying to get a fix working but hasn't succeeded in that yet. They could have worked with MSFT to make sure they aren't dragging their feet and actually continue on pushing a fix out but there was no reason for Google to disclose this (or not extend the embargo) aside from being dicks and doing it for a browser that is their direct competitor.
        Google acted irresponsibly in this case and there is no excuse!

        • (Score: 5, Funny) by takyon on Tuesday February 20 2018, @04:24PM (5 children)

          by takyon (881) <takyonNO@SPAMsoylentnews.org> on Tuesday February 20 2018, @04:24PM (#640706) Journal

          So the embargo window is there for a reason... but Google actually ending the embargo (albeit with a 14 day extension) is bad.

          What should they do instead? Extend the window repeatedly forever? Then it's no longer a window, it's windows.

          --
          [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
          • (Score: 2, Funny) by realDonaldTrump on Tuesday February 20 2018, @04:36PM (4 children)

            by realDonaldTrump (6614) on Tuesday February 20 2018, @04:36PM (#640713) Homepage Journal

            So many people who have computer, they have it for windows. For solitaire, for so many things. They love the solitaire, so interesting! Great job, Bill! Great job, Satya!

            • (Score: 3, Funny) by realDonaldTrump on Tuesday February 20 2018, @06:07PM (3 children)

              by realDonaldTrump (6614) on Tuesday February 20 2018, @06:07PM (#640759) Homepage Journal

              It's a day ending in "Y" so dumb & unfair downmodders are "reading." They're not reading. Because the STORY and the other TWEET are about windows! But I tweet about windows, suddenly it's "OFFTOPIC." Not because of what I wrote. Because of who I am!!!!

              • (Score: 2) by DannyB on Tuesday February 20 2018, @08:20PM

                by DannyB (5839) Subscriber Badge on Tuesday February 20 2018, @08:20PM (#640818) Journal

                Microsoft should make new Surface laptops powered by Clean Coal. Beautiful Clean Coal.

                --
                The lower I set my standards the more accomplishments I have.
              • (Score: 4, Interesting) by captain normal on Tuesday February 20 2018, @08:27PM (1 child)

                by captain normal (2205) on Tuesday February 20 2018, @08:27PM (#640821)

                The story and TFA are about a vulnerabilkity in MS's Edge brower that was discovered by Google's Project Zero. All the posts up to yours are about that toipic. Your post is not. So to me that seems your post could qualify as "Off topic".
                If you were down moded, it probably has nothing to do with who you are (or pretend to be). Likely it was because you didn't contribute to the actual discussion.

                --
                Everyone is entitled to his own opinion, but not to his own facts"- --Daniel Patrick Moynihan--
                • (Score: 0) by Anonymous Coward on Wednesday February 21 2018, @06:16AM

                  by Anonymous Coward on Wednesday February 21 2018, @06:16AM (#641052)

                  Oh man, it's Captain Normal, the arch-nemesis of Donald Trump!

        • (Score: 5, Insightful) by requerdanos on Tuesday February 20 2018, @04:52PM (1 child)

          by requerdanos (5997) Subscriber Badge on Tuesday February 20 2018, @04:52PM (#640723) Journal

          In this case, Google acted irresponsibly because the intent of the embargo was satisfied: MSFT has been trying to get a fix working but hasn't succeeded in that yet. They could have worked with MSFT to make sure they aren't dragging their feet and actually continue on pushing a fix out but there was no reason for Google to disclose this (or not extend the embargo)

          Microsoft is a large enough, not-100%-trustworthy enough organization for a judgment call like that to be fraught with uncertainty. Even now, the patch isn't out, and one may be in the works and may not; all we have are words.

          What has certainty is the disclosure program, which is pretty effective. That's a reason that might seem petty and spiteful, might even be petty and/or spiteful, but which was made in line with a policy that has a proven track record of improving security industry-wide.

          • (Score: 0) by Anonymous Coward on Tuesday February 20 2018, @05:12PM

            by Anonymous Coward on Tuesday February 20 2018, @05:12PM (#640733)

            OP here...
            You know what, you're not going to hear this often on the 'tubes, but the way you put it, I think you're right. I hereby recall my original post...

    • (Score: 1, Interesting) by Anonymous Coward on Wednesday February 21 2018, @09:06AM

      by Anonymous Coward on Wednesday February 21 2018, @09:06AM (#641081)

      The 90 days are there for marketing to get ready to spin it as not a problem, while the customers have no information about how to defend against attacks. If they could get more, they would take it. Before we started the 90 day thing, they would sit on problems for years, not fixing them until the attack became so widely known that they couldn't keep silent anymore.

      That marketing are given 90 days to spin it is already a sign that software is not a mature business. Warning customers and telling them how to take preventative measures until the patch is ready should be priority one, higher than even developing a patch.

      Imagine if it was discovered that a certain brand of cars had brakes that suddenly stop working. How big would the uproar be if they got 90 days before they are required to tell customers to park their cars and not move them until the brakes have been fixed?

  • (Score: 2) by Wootery on Tuesday February 20 2018, @04:31PM (4 children)

    by Wootery (2341) on Tuesday February 20 2018, @04:31PM (#640710)

    From TFA:

    if the content process can predict the address on which the JIT process is going to call its VirtualAllocEx() function next - which can be done fairly easily, according to Google - and it is compromised, the content process can:

    1. Unmap the shared memory mapped above above using UnmapViewOfFile()
    2. Allocate a writable memory region on the same address JIT server is going to write and write a soon-to-be-executable payload there.
    3. When JIT process calls VirtualAllocEx(), even though the memory is already allocated, the call is going to succeed and the memory protection is going to be set to PAGE_EXECUTE_READ.

    So it enables an attacker to escalate an exploit in an Edge 'content process' up into executing arbitrary instructions, if I understand correctly. But it doesn't give an attacker a new way in at the ground floor.

    • (Score: 4, Funny) by Wootery on Tuesday February 20 2018, @04:33PM

      by Wootery (2341) on Tuesday February 20 2018, @04:33PM (#640711)

      ...and too late I realise I never replaced my placeholder subject :-P

    • (Score: 2) by TheRaven on Tuesday February 20 2018, @04:49PM (2 children)

      by TheRaven (270) on Tuesday February 20 2018, @04:49PM (#640721) Journal

      I think that's right. It's not clear that this is actually exploitable, because to be able to meet the prerequisites you must already have compromised the content process enough that you can issue a system call (of your choice, with arguments of your choice), but not enough that you can execute arbitrary code. This is a pretty narrow window. It's basically useful only if you have a not-quite arbitrary code execution vulnerability that lets you run a small amount of arbitrary code and the CFI stuff in recent versions of Windows is good enough that you can't use this to start a code reuse attack that lets you run arbitrary code in some kind of weird machine made from gadgets in existing code. If you can already execute arbitrary code in the compromised process, then this doesn't give you anything else. If you can't execute arbitrary code, then it's unlikely that you can issue the system call.

      The one place where this might be interesting is if there is a separate vulnerability that lets you control the base address for an existing VirtualAlloc[Ex] call. In this case, you'd be able to elevate from a data injection to arbitrary code execution. That seems pretty unlikely though.

      --
      sudo mod me up
      • (Score: 3, Interesting) by Wootery on Tuesday February 20 2018, @05:11PM (1 child)

        by Wootery (2341) on Tuesday February 20 2018, @05:11PM (#640731)

        If you can already execute arbitrary code in the compromised process, then this doesn't give you anything else.

        I think that's it - the meat of the 'content' process space presumably runs with the NX bit set. TFA never mentions 'NX', but I presume that's what Microsoft's 'Arbitrary Code Guard' boils down to.

        arbitrary code in some kind of weird machine made from gadgets in existing code

        Ah, the war against ROP. Did Intel's 'Control-flow Enforcement Technology' ever go anywhere?

        If you can already execute arbitrary code in the compromised process, then this doesn't give you anything else.

        Assuming equal privileges between the content and JIT processes, at least.

        • (Score: 3, Informative) by TheRaven on Wednesday February 21 2018, @02:58PM

          by TheRaven (270) on Wednesday February 21 2018, @02:58PM (#641170) Journal

          I think that's it - the meat of the 'content' process space presumably runs with the NX bit set. TFA never mentions 'NX', but I presume that's what Microsoft's 'Arbitrary Code Guard' boils down to.

          It runs in W^X mode, and with most code non-executable. The important bit is that this process never generates new executable code, it maps a shared memory region as read-execute and another process maps it read-write. The other process runs the JIT and generates code, but the code generation and the execution of that code run in different processes so it's difficult to use the JIT to attack itself.

          Ah, the war against ROP. Did Intel's 'Control-flow Enforcement Technology' ever go anywhere?

          Yup, it's coming soon. We've done some reviews of it and it's pretty sensible. I wasn't actually talking about CET though, Microsoft Research has a pure software CFI scheme that is on by default on Windows 10 for all system applications and libraries and can be optionally enabled via Windows Update on Windows 7 and later.

          Assuming equal privileges between the content and JIT processes, at least.

          As I understand it, this doesn't help you attack the JIT process, it lets you map some memory write-execute in the content process, but only if you can issue a VirtualAlloc or VirtualAllocEx system call in the content process.

          --
          sudo mod me up
(1)