DOS a victim domain after opening attacker's link
Reported by
wadih.ma...@gmail.com,
Jul 22 2016
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36 Steps to reproduce the problem: 1.Open http://localhost/victimdomainpage.html 2.The victim domain has a link to attacker's domain (opened in the same renderer process). Open that link 3.Click on the attack button in the attacker's page http://127.0.1.1/attackpage1.html 4.Wait a bit 5-If the attack succeeded, the page http://localhost/victimdomainpage.html won't be able to navigate to any page (no refresh, back, clicking link) and all the setTimeout calls won't be executed (even if the setTimeout function was called before the attack). This state continues even after closing the attacker's pages. What is the expected behavior? The victim page http://localhost/victimdomainpage.html should work normally as before, regardless of what link was opened. What went wrong? As stated in step 5, http://localhost/victimdomainpage.html loses a lot of functionalities that even a refresh or closing the attacker's pages can't cure. Worse, the lost of some functionalities is silent (like the SetTimeout calls that don't trigger), and that can be problematic if the victim is relying on automatic updates of http://localhost/victimdomainpage.html (using setTimeouts) and the victim won't know if there is a problem or if there is no updates. Did this work before? N/A Chrome version: 51.0.2704.106 Channel: n/a OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Shockwave Flash 22.0 r0
,
Jul 22 2016
,
Aug 5 2016
Not sure what's happening, seems like the renderer is punished for doing something wrong on another site. Also not sure we can do anything about it. creis@ and nasko@ would probably be the best people to know ... I changed the files (see attached archive) slightly to make it reproducible by running in the directory: python -m SimpleHTTPServer (also changed the second link on the victim to wikipedia.org, to make the log less spammy with various QUIC spam, did not help much though) Ran with: rm -rf /tmp/u && gn_linux/Debug/chrome --user-data-dir=/tmp/u --enable-logging=stderr --v=1 http://localhost:8000/ The first click on wikpedia link did not reveal much: 14488:14488:0805/202050:VERBOSE1:app_url_redirector.cc(75)] Considering URL for redirection: https://wikipedia.org/ [14488:14488:0805/202050:VERBOSE1:app_url_redirector.cc(121)] Skipping redirection: no matching app handler found [1:1:0805/202050:VERBOSE1:mojo_proxy_resolver_impl.cc(60)] GetProxyForUrl(https://wikipedia.org/) [1:1:0805/202050:VERBOSE1:mojo_proxy_resolver_impl.cc(60)] GetProxyForUrl(https://www.wikipedia.org/) [1:1:0805/202050:VERBOSE1:mojo_proxy_resolver_impl.cc(100)] GetProxyForUrl(https://wikipedia.org/) finished with error 0. 1 Proxies returned: [1:1:0805/202050:VERBOSE1:mojo_proxy_resolver_impl.cc(103)] direct:// [14488:14516:0805/202050:VERBOSE1:proxy_resolver_factory_mojo.cc(234)] ProxyResolverMojo::Job::ReportResult: 0 [14488:14516:0805/202050:VERBOSE1:proxy_resolver_factory_mojo.cc(238)] Servers: DIRECT [14488:14516:0805/202051:VERBOSE1:spdy_session_key.cc(21)] SpdySessionKey(host=wikipedia.org:443, proxy=direct://, privacy=0 [1:1:0805/202051:VERBOSE1:mojo_proxy_resolver_impl.cc(100)] GetProxyForUrl(https://www.wikipedia.org/) finished with error 0. 1 Proxies returned: [1:1:0805/202051:VERBOSE1:mojo_proxy_resolver_impl.cc(103)] direct:// [14488:14516:0805/202051:VERBOSE1:proxy_resolver_factory_mojo.cc(234)] ProxyResolverMojo::Job::ReportResult: 0 [14488:14516:0805/202051:VERBOSE1:proxy_resolver_factory_mojo.cc(238)] Servers: DIRECT [14488:14516:0805/202051:VERBOSE1:spdy_session_key.cc(21)] SpdySessionKey(host=www.wikipedia.org:443, proxy=direct://, privacy=0 [14488:14516:0805/202051:VERBOSE1:resource_loader.cc(262)] OnReceivedRedirect: https://wikipedia.org/ [1:1:0805/202051:VERBOSE1:mojo_proxy_resolver_impl.cc(60)] GetProxyForUrl(https://www.wikipedia.org/) [1:1:0805/202051:VERBOSE1:mojo_proxy_resolver_impl.cc(100)] GetProxyForUrl(https://www.wikipedia.org/) finished with error 0. 1 Proxies returned: [1:1:0805/202051:VERBOSE1:mojo_proxy_resolver_impl.cc(103)] direct:// [14488:14516:0805/202051:VERBOSE1:proxy_resolver_factory_mojo.cc(234)] ProxyResolverMojo::Job::ReportResult: 0 [14488:14516:0805/202051:VERBOSE1:proxy_resolver_factory_mojo.cc(238)] Servers: DIRECT [14488:14516:0805/202051:VERBOSE1:spdy_session_key.cc(21)] SpdySessionKey(host=www.wikipedia.org:443, proxy=direct://, privacy=0 [1:1:0805/202051:VERBOSE1:ScheduledAction.cpp(116)] ScheduledAction::execute 0x3395f79dcba0: have function [1:1:0805/202051:VERBOSE1:ScheduledAction.cpp(116)] ScheduledAction::execute 0x3395f79dcc58: have function [1:1:0805/202051:VERBOSE1:ScheduledAction.cpp(116)] ScheduledAction::execute 0x3395f79dcd10: have function [1:1:0805/202051:VERBOSE1:ScheduledAction.cpp(116)] ScheduledAction::execute 0x3395f79dd9f0: have function [14488:14516:0805/202053:VERBOSE1:media_stream_dispatcher_host.cc(144)] MediaStreamDispatcherHost::OnChannelClosing [14488:14516:0805/202053:VERBOSE1:node_controller.cc(520)] Dropped peer 22CE8E5BD78C7E06.808941A9D8A0BAD0 [14531:14579:0805/202053:VERBOSE1:node_controller.cc(520)] Dropped peer 22CE8E5BD78C7E06.808941A9D8A0BAD0 [14488:14516:0805/202053:VERBOSE1:node.cc(410)] Observing lost connection from node E240CB6958DD58C7.366DCF5C0AB0D66C to node 22CE8E5BD78C7E06.808941A9D8A0BAD0 [14531:14579:0805/202053:VERBOSE1:node.cc(410)] Observing lost connection from node A54C9EE2B1F647FA.B68F7BC5BCAAAE7F to node 22CE8E5BD78C7E06.808941A9D8A0BAD0 [14531:14579:0805/202053:VERBOSE1:ipc_sync_channel.cc(423)] Canceling pending sends [14531:14531:0805/202053:VERBOSE1:ipc_sync_channel.cc(423)] Canceling pending sends [14531:14579:0805/202053:VERBOSE1:ipc_sync_channel.cc(423)] Canceling pending sends [14531:14579:0805/202053:VERBOSE1:node.cc(410)] Observing lost connection from node A54C9EE2B1F647FA.B68F7BC5BCAAAE7F to node 22CE8E5BD78C7E06.808941A9D8A0BAD0 [14488:14488:0805/202053:VERBOSE1:node_controller.cc(647)] Dropping message for unknown peer: 22CE8E5BD78C7E06.808941A9D8A0BAD0 [14531:14579:0805/202053:ERROR:node_controller.cc(1099)] Could not be introduced to peer 22CE8E5BD78C7E06.808941A9D8A0BAD0 Second click on the wikipedia link is more interesting: [14488:14488:0805/202203:VERBOSE1:cross_device_promo.cc(169)] CrossDevicePromo::MaybeBrowsingSessionStarted. Same browsing session as the last call. [14488:14516:0805/202204:VERBOSE1:resource_loader.cc(500)] CancelRequestInternal: https://wikipedia.org/ [14488:14516:0805/202204:VERBOSE1:resource_loader.cc(346)] OnResponseStarted: https://wikipedia.org/ [14488:14516:0805/202204:VERBOSE1:resource_loader.cc(659)] ResponseCompleted: https://wikipedia.org/ [14488:14488:0805/202204:VERBOSE1:navigator_impl.cc(203)] Failed Provisional Load: https://wikipedia.org/, error_code: -3, error_description: The webpage at <strong jscontent="failedUrl"></strong> might be temporarily down or it may have moved permanently to a new web address., showing_repost_interstitial: 0, frame_id: 1 [14488:14488:0805/202204:VERBOSE1:app_url_redirector.cc(75)] Considering URL for redirection: https://wikipedia.org/ [14488:14488:0805/201853:VERBOSE1:navigator_impl.cc(203)] Failed Provisional Load: https://wikipedia.org/, error_code: -3, error_description: The webpage at <strong jscontent="failedUrl"></strong> might be temporarily down or it may have moved permanently to a new web address., showing_repost_interstitial: 0, frame_id: 2
,
Aug 16 2016
I finally had some time to poke a this and understand what is going on. It is a fun interaction between several different features that combine to give us the repro.
The navigation to a page with invalid SSL certificate gives us an interstitial page. The current implementation of interstitials done through an overlay on top of the real page, which keeps on running in the background. Since it is in the same process with the other pages, they share the same event loop.
The navigation to attackerpage2.html happens in the real page underneath the interstitial, which only does "window.print();". However, since we have the interstitial overlay, the print preview dialog does not show up on the screen, so the user isn't aware and cannot dismiss it.
Print preview window is implemented as a modal dialog and a sync IPC message, which means that the renderer process is basically blocked from making any progress. This gives the attacker the capability to stop all setTimeout and other JavaScript code execution for the entire process, so all tabs using it are more or less stuck.
I've tried a very simple and naive fix that seems to work:
diff --git a/chrome/browser/printing/print_view_manager.cc b/chrome/browser/printing/print_view_manager.cc
index b50a5ba..bc74e32 100644
--- a/chrome/browser/printing/print_view_manager.cc
+++ b/chrome/browser/printing/print_view_manager.cc
@@ -164,6 +164,13 @@ void PrintViewManager::OnSetupScriptedPrintPreview(IPC::Message* reply_msg) {
g_scripted_print_preview_closure_map.Get();
content::RenderProcessHost* rph = web_contents()->GetRenderProcessHost();
+ // The print dialog should not be opened if the WebContents is displaying
+ // an interstitial page.
+ if (web_contents()->ShowingInterstitialPage()) {
+ Send(reply_msg);
+ return;
+ }
+
// This should always be 0 once we get modal window.print().
if (map.count(rph) != 0) {
// Renderer already handling window.print() in another View.
However, I will be out of office for a bit so I won't be able to put up a CL to actually fix this. I'm assigning it for now to thestig@ for further triage to the correct person or fixing it if possible. I can come back to this in September if noone has had a chance to fix it.
,
Sep 7 2016
Oh window.print(), what a pain. Comment 4 is on the right track. We should handle the "is crashed" state to be consistent with other places that initiate printing, and also handle the non-print-preview case. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by kerrnel@chromium.org
, Jul 22 2016Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Type-Bug