this will be three sub-bugs I imagine, the GPU buffer overflow, the sandbox escape  and the smartscreen bypass

full chain sandbox escape -> P-0 critical

+CC nparker since the exploit uses bat files to bypass safebrowsing and smartscreen.

595836 - tracks memory corruption in angle.
595838 - tracks safebrowsing bypass.

more coming

Some testing has shown that the full chain only works iff smartscreen is enabled.

If smartscreen is enabled then the Zone.Identifier ADS on the batch file is

[ZoneTransfer]
AppZoneId=4

if smartscreen is disabled (as it was on the ZDI laptop), then the Zone.Identifier ADS is:

[ZoneTransfer]
ZoneId=3

and the exploit fails.

To be clear, the last part of the full chain PDF describing the smartscreen bypass is not used in the PoC.zip as it just spawns cmd.exe so you won't find that code, it's only in the PDF.

ZoneID=3 is the "Mark-of-the-Web" indicating that the file originated from the Internet Zone. The presence of this ZoneID triggers various logic to confirm execution with the user. (https://blogs.msdn.microsoft.com/ieinternals/2011/03/23/understanding-local-machine-zone-lockdown/)

AppZoneID=4 is what gets written to the Zone.Identifier stream if SmartScreen's call out to w.apprep.smartscreen.microsoft.com returns ALLW:100 ("allow") for the file based on the information supplied (filename, hash of file, etc). The intent here is to allow "Known Safe" files to execute without additional prompting.

It *appears* that there's an explicit whitelist for this file hash (as a file containing "g" rather than "f" results in the AppRep service returning UNKN:100 which results in a SmartScreen "Unknown File Blocked" dialog box.

A file containing the text "g" results in the following from https://w.apprep.smartscreen.microsoft.com/ArsWindows.asmx

    <?xml version="1.0"?><Rs E="0" V="5.0">

    <App><ApRt>UNKN:100</ApRt><UX>1</UX></App>

    <S><Ext>.cpl,.exe,.dll,.ocx,.sys,.scr,.drv,.msi,.com,.pif,.bat,.cmd,.vbe,.msu,.gadget,.website,.jse,.vbs,.lnk,.ps1,.vb,.js,.appref-ms,.wsf,.iso,.vxd,.vhd,.vhdx</Ext><Sux>1</Sux>
    <MS>-1</MS><Stw>100</Stw><Scw>100</Scw><Sx>0.05</Sx><Skg>0.1</Skg></S></Rs>


A file containing the text "f" results in the following from https://w.apprep.smartscreen.microsoft.com/ArsWindows.asmx

    <?xml version="1.0"?><Rs E="0" V="5.0">

    <App><ApRt>ALLW:100</ApRt><UX>1</UX></App>

    <S><Ext>.cpl,.exe,.dll,.ocx,.sys,.scr,.drv,.msi,.com,.pif,.bat,.cmd,.vbe,.msu,.gadget,.website,.jse,.vbs,.lnk,.ps1,.vb,.js,.appref-ms,.wsf,.iso,.vxd,.vhd,.vhdx</Ext><Sux>1</Sux>
    <MS>-1</MS><Stw>100</Stw><Scw>100</Scw><Sx>0.05</Sx><Skg>0.1</Skg></S></Rs>

Beyond the SmartScreen problem, allowing unconfirmed downloads to any user-visible folder (especially a folder where programs are run) could be a vector for exploitation, akin to DLL hijacking (https://textplain.wordpress.com/2015/12/18/dll-hijacking-just-wont-die/). For that case, we've prevented writes of unconfirmed DLL downloads to the Downloads folder, but it's entirely possible that even without SmartScreen we could be vulnerable with other file types. An attacker would write a .bat or .cmd file to the folder and wait for some other legitimate but buggy program to be run from that folder. 

https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/download/download_extensions.cc&q=kDownloadFileTypes&sq=package:chromium&l=214

    // Command script.
    {"bat", ALLOW_ON_USER_GESTURE, DISALLOW_AUTO_OPEN},
    {"cmd", ALLOW_ON_USER_GESTURE, DISALLOW_AUTO_OPEN},

re: #12 - Microsoft were in the disclosure room at Pwn2Own and are aware of the Smartscreen issues.

Pri-0 bugs are critical regressions or serious emergencies, and this bug has not been updated in three days. Could you please provide an update, or adjust the priority to a more appropriate level if applicable?

If a fix is in active development, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Pri-0 bugs are critical regressions or serious emergencies, and this bug has not been updated in three days. Could you please provide an update, or adjust the priority to a more appropriate level if applicable?

If a fix is in active development, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Assigning to wfh@ to shepherd this bug through the process.

wfh@: This seems to have fallen off the radar.  Should it have been marked fixed?

I notice that the GPU buffer overflow is fixed ( issue 595836 ), the escalation from GPU to arbitrary renderer is fixed ( issue 596862 ), and the use of bat files to avoid SafeBrowsing is fixed (issue 595838).

In comment 4, you also mentioned the SmartScreen bypass, which is still listed as open at  issue 595844 , though I'm wondering if that's out of date.

This bug also lists issue 595841 as a blocker, but I don't think it should be.  Issue 595841 was about a second line of defense to make it harder for attackers to take over chrome://downloads from other chrome:// URLs.  That would be nice to have, but not necessary for considering this bug fixed.

I agree with analysis in #20 and this should be marked Fixed.

Thanks!  Removing issue 595841 as a blocker.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot