In the scenario described, an attacker has achieved arbitrary code execution in the host operating system through an unspecified vector, and controls the arguments used to launch Chrome.

Why would an attacker with this level of permission bother using Chrome at all, instead of exfiltrating data directly via his/her existing ability to execute arbitrary code?

I concur with #1 that this seems to be outside our threat model and certainly not a security bug.

However my interest is piqued by your claim that --user-data-dir changes any behavior at all for Chrome, as the html is written to the parent directory of the profile and so should not change any behavior (in fact I don't think it would even change behavior if it were inside the profile directory)

Can you explain in more details your perceived consequences of using --user-profile-dir to change Chrome's behavior?

#1: As I explained, I was playing with the various post-exploitation ways to exfiltrate data from an infected machine. One of those ways was to use chrome as the channel in which data would be exchanged making it stealthier and less obvious to Incident-respondents. Combining chrome, a legitimate process which often goes online, and its instant support to the WebRTC protocol, which establishes a P2P data exchange in an encrypted manner, makes it a very interesting scenario.

#2: I would suggest to open a Powershell terminal and copy-paste the script (maybe without the last part which hide's the relevant process).
The command that works is:
start chrome "--disable-web-security  --chrome-frame --window-size=1,1 --window-position=1,1  --app=$malHTML --user-data-dir=$userdatadir".
*$malHTML refers to the HTML page that gets written locally and contains Javascript code and an iframre pointing to the WebRTC file sharing site.
*$userdatadir refers to a random directory, it makes no difference.
*--chrome-frame, --window-size, --window-position were added for making the POC stealthier. They make no difference in this context so I'll just ignore them.

When applying changes to the script in the form of removing specific chrome arguments, it will raise errors which makes this whole scenario useless:

-test #1: Start chrome --app=$malHTML
In this test case, we get an iframe with a file:// protocol attempting to access an http:// location and gets block with a Same-Origin policy error.

-test #2: Start chrome --disable-web-security --app=$malHTML
In this test case, we were able to overcome the previous error by supplying the "--disable-web-security" argument but now we get a new error: "DOMException: Blocked a frame with origin "null" from accessing a cross-origin frame."

-test #3: Start chrome --disable-web-security --user-data-dir=$userdatadir --app=$malHTML
In this test case, we get no errors and the Javascript code is able to run and retrieve information from the iframe and manipulate it as it sees fit.

*Any other permutation of the above chrome arguments will end up in one of the mentioned errors.

I can't tell why the addition of --user-data-dir bypasses the errors but as shown above it does that.
I would very much like to know why --user-data-dir makes such a difference without being stated so in the docs.
It may not be your classical security bug but as shown above, it could be used to fuel this given scenario which enables an attacker a way to hide all of his post-exploitation communication behind a legitimate chrome process and encrypted WebRTC packets.

As before, please ask away.

Thanks,
Amit

Thank you for providing more feedback. Adding requester "wfh@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Re #3: Sure, but there are myriad other better/simpler ways you could do this after you have code execution in the system. You could rewrite Chrome's binary. You could perform DLL hijacking. You could write files to steal into base64'd blobs in local HTML pages that 'POST' the data to web servers, etc. 

Your "-test #2" case probably should not have failed (--disable-web-security is intended to do just that. However, this is a functional problem in an off-by-default, dangerous mode.

Ok so it's irrelevant?

As said previously, this is not a security bug. However I continue to be surprised that specifying --user-data-dir makes any difference to the behavior of the browser security policy. Can you try with another completely different --user-data-dir e.g. on another drive or completely different folder, and try and narrow down whether it is consequential that the user data dir has the same folder prefix as the app html?

Can you generate a minimal repro case that does not involve setting --disable-web-security? I strongly suspect that is what is disabling the SOP (that's the flag's purpose), and not --user-data-dir by itself.

Re #8: As far as I can tell, in #3 the reporter is saying "--disable-web-security" isn't disabling SOP completely, and the additional "--user-data-dir" is needed to get the --disable-web-security flag to work properly and avoid the "DOMException: Blocked a frame with origin "null" from accessing a cross-origin frame." error.

I can reproduce this with Chrome Canary.

Simpler repro is to drop the attached "malware.html" file in your C:\src\temp\ directory.

From a Windows command prompt, execute:

 start chrome --disable-web-security --chrome-frame --app=C:\src\temp\malware.html

Right-click the frame and choose "Inspect". Observe that cross-origin data access was unexpectedly blocked:

malware.html:6 Uncaught DOMException: Blocked a frame with origin "null" from accessing a cross-origin frame.
    at checkLinks (file:///C:/src/temp/malware.html:6:82)
    at HTMLIFrameElement.onload (file:///C:/src/temp/malware.html:13:145)

Next, try with a user-data folder: 

  start chrome --disable-web-security --chrome-frame --app=C:\src\temp\malware.html --user-data-dir=c:\temp

Right-click the frame and choose "Inspect". Observe: No script error. Console says "0 links found. 1 links found." demonstrating that cross-origin data access was allowed as expected.

Deleted: malware.html 605 bytes

malware.html 605 bytes View Download

This appears to be by-design:

https://cs.chromium.org/chromium/src/chrome/browser/chrome_content_browser_client.cc?type=cs&l=2640

    LOG(ERROR) << "Web security may only be disabled if '--user-data-dir' is "
               "also specified.";

ah thanks, okay I did not know that, this explains why --user-data-dir is required. Certainly WontFix.

It turns out that this requirement was introduced in the waning days of 2015: https://crrev.com/a1f7749bb0d8e5934d6b0c3adafbf0cb47cf7815

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