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.
  • (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
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (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