Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Security: URL Spoof with http authentication dialog and pdf prompt dialog
Reported by chamal.d...@gmail.com, Apr 29 2015 Back to list
VULNERABILITY DETAILS
This bug can display a prompt dialog box through a pdf file, under a url of a different origin, which displays an http authentication dialog box.

VERSION
Chrome Version: [42.0.2311.135 ] + [stable]
                [44.0.2384.0] + [trunk build]
Operating System: [Windows 8, Ubuntu 14.04]

REPRODUCTION CASE
Required software: Web server with support for php.
                   Web server should serve content from 127.0.0.1 and 127.0.0.2.
                   Enable chrome pdf plugin if it is disabled.

1. Download urlspoof3.html, auth.php, formsubmit.pdf, pdfForm.php and userresponse.php.
2. Host downloaded files on local web server's root folder.
3. Open chrome
4. Visit http://127.0.0.1/urlspoof3.html
   http://127.0.0.1/urlspoof3.html will load formsubmit.pdf.
5. formsubmit.pdf will display a prompt dialog which will ask user's age.
6. After 2 seconds page will be redirected to http://127.0.0.2/auth.php
7. But confirm dialog displayed from http://127.0.0.1/urlspoof3.html will remain.
   Authenitication dialog displayed from http://127.0.0.2/auth.php will be visible under confirm dialog.
8. Enter a number in prompt dialog and press OK.
9. Wait 5 seconds.
   formsubmit.pdf will submit number typed by user to http://127.0.0.1/pdfForm.php
   But this form submission will be not visible through browser UI.
   This form submission request will be visible in web server's access log file.
10. Open a new tab and visit http://127.0.0.1/userresponse.php
    userresponse.php will display number typed by user.

* formsubmit.pdf contains javascript code to display Confirm message box and to submit form. You can view this code by opening formsubmit.pdf in a pdf editor and viewing code for Javascript OpenAction.


 
urlspoof3.html
181 bytes View Download
userresponse.php
167 bytes View Download
formsubmit.pdf
1.5 KB Download
pdfForm.php
81 bytes View Download
auth.php
177 bytes View Download
This bug is separated from  issue 477278 .
Please see comment 13 of  issue 477278 .
Comment 2 by creis@chromium.org, Apr 29 2015
Cc: nasko@chromium.org creis@chromium.org f...@chromium.org meacer@chromium.org
Labels: Cr-Internals-Plugins-PDF Security_Impact-Stable Security_Severity-Medium
Owner: raymes@chromium.org
Status: Assigned
Assigning labels based on the previous bug.

@raymes: Can you take a look?

@meacer: Do you think this should be medium or low severity?  In the similar  issue 295695 , comment 28 rated it as low because (1) it depends on the victim site showing an interstitial and (2) the prompt is a limited form of a spoof.  In this case, the spoof is a bit more effective against sites that use HTTP auth, since the user is already expecting a dialog for entering a password and they might put it into the wrong dialog.  Tentatively assigning medium severity.
Project Member Comment 3 by clusterf...@chromium.org, Apr 29 2015
Labels: Pri-1
Status: Started
Comment 5 by palmer@google.com, May 1 2015
Cc: palmer@chromium.org tsepez@chromium.org
Labels: M-44 Cr-Security-UX
Hmm it would be great if someone with more WebContentsImpl knowledge could chime in here. I'm seeing something quite interesting. WebContentsImpl::DidStartProvisionalLoad gets fired during the redirect but it doesn't seem to get further than that, and so I don't think there is anything in the code that will cause the dialogs to disappear by that stage. I guess that the modal credentials dialog prevents it from getting further.

As to why this doesn't happen in other circumstances (e.g. with iframes popping alerts, etc.) usually this jams up the renderer from being able to do anything else since everything is running in the same process. So the redirect will never get hit until the modal dialogs are clicked away. However in our case we have a BrowserPlugin running in a separate process from the embedder so the redirect is running in parallel with the alert dialog.

So my gut feeling is that we will actually see this problem occur with OOPIF as well. I tried to test this theory however it appears that modal dialogs don't work at all when coming from cross-process iframes at present.
creis: do you have any suggestions regarding #6? Thanks!
Comment 8 by raymes@chromium.org, May 11 2015
ping
Comment 9 by creis@chromium.org, May 18 2015
Sorry, I was out on vacation.  (Really wish there was a OOO setting for crbug.)

Can you point me to the code that puts up the dialog in the PDF case?  It doesn't seem to go through WebContentsImpl::RunJavaScriptMessage, and I don't know where to look.
Comment 11 by creis@chromium.org, May 19 2015
Thanks!  I'll try to catch that in a debugger to see what to suggest.
Comment 12 by creis@chromium.org, May 19 2015
Cc: fsam...@chromium.org lazyboy@chromium.org
Labels: Cr-Platform-Apps-BrowserTag
I think I see what's happening.  The inner (guest) WebContents is showing the dialog via WebContentsImpl::RunJavaScriptMessage (contrary to what I said in comment 9), which gives it a dialog_manager_.

Later, the *outer* (embedder) WebContents shows an interstitial page.  That gets to WebContentsImpl::AttachInterstitialPage, which would normally call dialog_manager_->CancelActiveAndPendingDialogs(this) to dismiss any modal dialogs once the interstitial is shown.  However, dialog_manager_ is still null in the outer (embedder) WebContents, so it doesn't call CancelActiveAndPendingDialogs.

This seems like a problem with BrowserPlugin.  The guest is maintaining dialog state, and the embedder is trying to clear it.  Ideally the guest would let the embedder handle the operation directly, but that seems unlikely in this case (e.g., because RunJavaScriptMessage is closely tied to the RenderFrameHost in the guest).  OOPIFs won't face this because they share the same WebContents.

lazyboy@/fsamuel@: How do you usually handle this type of problem with BrowserPlugin?  Should the embedder tell all of its guests to CancelActiveAndPendingDialogs (in all the places it would normally do that itself)?  Is it even possible to iterate over all of its guests?
Cc: paulmeyer@chromium.org wjmaclean@chromium.org
@12, Yes, we do have "broadcast to all guests" pattern:
For example we broadcast when system's screen info changes:
WebContentsImpl::ScreenInfoChanged() ->
BrowserPluginEmbedder::ScreenInfoChanged() ->
GetBrowserPluginGuestManager()->ForEachGuest(web_contents(), base::Bind(
      &BrowserPluginEmbedder::NotifyScreenInfoChanged));
ref:
https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/browser_plugin/browser_plugin_embedder.cc&l=64
It seems like having the embedder broadcast to all guests to CancelActiveAndPendingDialogs() is sensible, though I've just started to read this thread and it's possible I'm missing something.

Are there other places where we have duplicate state across embedder/guest that we should be concerned about? Maybe unrelated, but I recently noticed that opening a PDF inside another WebView (e.g. in BrowserSample) allows the PDF inside the webview to generate a context-navigation menu, and open a tab in the main browser context ... that also seems like a potential problem (I've filed this issue as: https://code.google.com/p/chromium/issues/detail?id=489939).
Cc: raymes@chromium.org
Owner: wjmaclean@chromium.org
wjmaclean/paulmeyer - is it ok if I assign to one of you since it's more generally BrowserPlugin related?
Please do let me know if you won't have time for this though. Thanks!
Comment 18 by creis@chromium.org, May 20 2015
Comment 15: Yeah, I'd be concerned about this type of bug happening in other parts of WebContents.  It could probably happen anywhere that the inner guest WebContents has some state that the user interacts with via the outer embedder WebContents...

For this bug, I'm ok with having the embedder tell its guests in all the places that WebContentsImpl calls CancelActiveAndPendingDialogs.  We should think about ways to generalize this to work better for other (and future) cases, though.
Comment 19 by creis@chromium.org, May 20 2015
Cc: a...@chromium.org
Exploring a possible solution here:
https://codereview.chromium.org/1150843002/

Also CC'ing Avi for context on dialogs and interstitials.
Labels: Cr-Internals-Network-Auth
Comment 22 by creis@chromium.org, May 27 2015
Status: Fixed
Should be fixed in r331584.  We should be able to verify in tomorrow's canary to decide whether to merge the fix.
Project Member Comment 23 by clusterf...@chromium.org, May 27 2015
Labels: -Restrict-View-SecurityTeam M-43 Restrict-View-SecurityNotify Merge-Triage
Adding Merge-Triage label for tracking purposes.

Once your fix had sufficient bake time (on canary, dev as appropriate), please nominate your fix for merge by adding the Merge-Requested label.

When your merge is approved by the release manager, please start merging with higher milestone label first. Make sure to re-request merge for every milestone in the label list. You can get branch information on omahaproxy.appspot.com.

- Your friendly ClusterFuzz
Labels: Merge-Request-44
Verified the fix.  This has been live since 45.0.2415.0 and is looking safe to merge.  (I had a brief scare from issue 495214, which was a crash involving extension dialogs that started in the same timeframe as this CL, but there's another CL responsible for that one.)

Ok to merge this to M44?
Labels: -Merge-Request-44 Merge-Approved-44 Hotlist-Merge-Approved
Approved for M44 (branch: 2403)
Project Member Comment 26 by bugdroid1@chromium.org, Jun 2 2015
Labels: -Merge-Approved-44 merge-merged-2403
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0fc455a3b21e2a6ac68771641c2a4b04008349c0

commit 0fc455a3b21e2a6ac68771641c2a4b04008349c0
Author: creis <creis@chromium.org>
Date: Tue Jun 02 01:15:13 2015

Dismiss browser plugin modal dialogs when the embedder needs to.

Test from wjmaclean@.  PDF simply shows an alert dialog using script.

TBR=nasko,sky
BUG= 482380 
TEST=See bug for repro steps.
NOTRY=true
NOPRESUBMIT=true

Review URL: https://codereview.chromium.org/1150843002

Cr-Commit-Position: refs/heads/master@{#331584}
(cherry picked from commit 89a0f782193755ad7a0b93c58dbcc1b96528405f)

Review URL: https://codereview.chromium.org/1153873005

Cr-Commit-Position: refs/branch-heads/2403@{#165}
Cr-Branched-From: f54b8097a9c45ed4ad308133d49f05325d6c5070-refs/heads/master@{#330231}

[modify] http://crrev.com/0fc455a3b21e2a6ac68771641c2a4b04008349c0/chrome/browser/ui/browser_browsertest.cc
[add] http://crrev.com/0fc455a3b21e2a6ac68771641c2a4b04008349c0/chrome/test/data/alert_dialog.pdf
[modify] http://crrev.com/0fc455a3b21e2a6ac68771641c2a4b04008349c0/content/browser/browser_plugin/browser_plugin_embedder.cc
[modify] http://crrev.com/0fc455a3b21e2a6ac68771641c2a4b04008349c0/content/browser/browser_plugin/browser_plugin_embedder.h
[modify] http://crrev.com/0fc455a3b21e2a6ac68771641c2a4b04008349c0/content/browser/web_contents/web_contents_impl.cc
[modify] http://crrev.com/0fc455a3b21e2a6ac68771641c2a4b04008349c0/content/browser/web_contents/web_contents_impl.h

Labels: Merge-Request-43
Shall I merge this to M43 as well?
Labels: -Merge-Request-43 Merge-Review-43 Hotlist-Merge-Review
[Automated comment] Request affecting a post-stable build (M43), manual review required.
Project Member Comment 29 by bugdroid1@chromium.org, Jun 3 2015
The following revision refers to this bug:
  https://chrome-internal.googlesource.com/bling/chromium.git/+/0fc455a3b21e2a6ac68771641c2a4b04008349c0

commit 0fc455a3b21e2a6ac68771641c2a4b04008349c0
Author: creis <creis@chromium.org>
Date: Tue Jun 02 01:15:13 2015

Cc: dxie@chromium.org
@dxie: Friendly ping: should I merge this to M43?
Cc: -dxie@chromium.org lafo...@chromium.org
laforge is the release manager for M43, not dxie.
Comment 32 by creis@chromium.org, Jun 12 2015
Labels: -M-43 -Merge-Review-43
We'll stick with M44 for this one.
Cc: timwillis@chromium.org
Labels: -Merge-Triage reward-topanel Release-0-M44
Labels: CVE-2015-1278
Labels: -reward-topanel reward-500 reward-unpaid
As mentioned in the release notes, $500 for this report as well. We'll be in contact to collect details, though please contact me at timwillis@ if you haven't heard from our finance department in a week.
Labels: -reward-unpaid reward-inprocess
Project Member Comment 37 by clusterf...@chromium.org, Sep 2 2015
Labels: -Restrict-View-SecurityNotify
Bulk update: removing view restriction from closed bugs.
Labels: -reward-inprocess
Processing via our e-payment system takes ~7 days, but the reward should be on its way to you. Thanks again for your help!
Project Member Comment 39 by sheriffbot@chromium.org, Oct 1 2016
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
Project Member Comment 40 by sheriffbot@chromium.org, Oct 2 2016
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
Labels: allpublic
Components: -Security>UX
Labels: Team-Security-UX
Security>UX component is deprecated in favor of the Team-Security-UX label
Sign in to add a comment