New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 747864 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jul 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Security



Sign in to add a comment

Cross-origin frame gets hint that it is framed by a local file

Reported by s.h.h.n....@gmail.com, Jul 24 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36

Steps to reproduce the problem:
1. Download and open attachment from local
2. Alert dialog says null

What is the expected behavior?
No info about local file should be leaked to cross origin frame.

What went wrong?
I know Chrome don't care much about ancestors info leaked through ancestorOrigins. But this info leak is abusive. Suppose Electron App renders some 3rd party's site in iframe. And suppose that 3rd party site has ads, which detects that ancestor origin includes null (which means file:///), then below code would run.

window.top.location="data:text/html, <script>require('child_process').exec('calc.exe',null);</script>"; 

Did this work before? N/A 

Chrome version: 59.0.3071.115  Channel: stable
OS Version: 10.0
Flash Version:
 
check.htm
92 bytes View Download
Components: Blink>SecurityFeature>SameOriginPolicy
Summary: Cross-origin frame gets hint that it is framed by a local file (was: Cross origin frame gets info of being framed by local file)
I'd expect there are other scenarios where the ancestor origin includes null, including those where a sandboxed origin is in use.

This doesn't seem terribly interesting from a Chrome point-of-view; in contrast, if an Electron application allows execution of web-supplied content, that would be a critical bug in such an application. There are likely other hints available to web content when it is being hosted by Electron, and a malicious ad could simply try the attack with or without the clue.

Comment 2 by vakh@chromium.org, Jul 26 2017

Cc: mkwst@chromium.org dcheng@chromium.org
+ mkwst@, dcheng@ to weigh in.

Comment 3 by mkwst@chromium.org, Jul 26 2017

1. As elawrence@ notes, `<iframe sandbox>` and `Content-Security-Policy: sandbox` will have the same effect. `null` is the serialization of an opaque origin, not a direct mapping to `file:///`.

2. We block navigation to `data:` at the top-level. :)

3. As elawrence@ also notes, it would indeed be a bad idea for Electron to expose native code execution to any and all content it loaded. If that PoC works, then it seems reasonable to suggest to the Electron project that they rethink how they inject powerful bindings (and to application developers that they consider sandboxing untrusted content without the `allow-top-navigation` flag).
As I reported previously, iframe sandbox does not return null for ancestorOrigins(https://bugs.chromium.org/p/chromium/issues/detail?id=722782).

Other Electron RCE are available here
https://www.slideshare.net/codeblue_jp/cb16-hasegawa-en

Comment 5 by mkwst@chromium.org, Jul 26 2017

> iframe sandbox does not return null for ancestorOrigins(https://bugs.chromium.org/p/chromium/issues/detail?id=722782).

That bug suggests that a sandboxed frame can read `ancestorOrigins`, which is true. My claim here was that a sandboxed frame will show up as `null` in the list of ancestor origins, which I hope is also true. I checked quickly with the following, and it seems to work the way I think it does:

```
<iframe sandbox="allow-scripts" srcdoc="
    <iframe srcdoc='
        <script>console.log(location.ancestorOrigins[0])</script>
    '></iframe>
"></iframe>
```

It looks like Electron does some things that make XSS inside of an app pretty dangerous. I don't think that changing the way that `ancestorOrigins` works address any of the concerns, however.
Allegedly, the snippet "window && window.process && window.process.type" will reveal whether JavaScript code is running inside an Electron renderer.

I don't think there's anything for Chrome to do here.
>That bug suggests that a sandboxed frame can read >`ancestorOrigins`, which is true. My claim here was >that a sandboxed frame will show up as `null` in the >list of ancestor origins, which I hope is also true.

Okay, I misunderstood that. yeah, it might be true.
Status: WontFix (was: Unconfirmed)
I don't think there's anything Chrome needs to do here.
Project Member

Comment 9 by sheriffbot@chromium.org, Nov 4 2017

Labels: -Restrict-View-SecurityTeam allpublic
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

Sign in to add a comment