Signing into Chrome causes Segmentation Fault/Core Dump with authenticated proxy requirement
Reported by
bernard_...@debortoli.com.au,
Nov 9 2016
|
|||||
Issue descriptionChrome Version (from the about:version page): 53.0.2785.143 Is this the most recent version: yes (for Ubuntu 16.04) OS + version: Ubuntu 16.04 CPU architecture (32-bit / 64-bit): 64 bit Window manager: KDE URLs (if relevant): Behavior in Linux Firefox: Segmentation Fault when I try to login Behavior in Windows Chrome (if you have access to it): What steps will reproduce the problem? (1) Configure proxy settings to use an authenticated proxy (2) Click the user icon in the title bar, and choose [Sign into Chromium] (3) A dialog overlay and spinning logo appear briefly -> segfault What is the expected result? A dialog overlay appears where I can enter my username and password What happens instead? The browser crashes with the message: > Segmentation fault (core dumped) Please provide any additional information below. Attach a screenshot and backtrace if possible. strace output attached Videos of the process (failing with auth proxy, working with no auth proxy): mp4: https://drive.google.com/file/d/0B3HLJgx8Sj1WeDdQb1RqZWVualk/view?usp=sharing ogv: https://drive.google.com/file/d/0B3HLJgx8Sj1WT2hZZHRreVY2aVk/view?usp=sharing
,
Nov 9 2016
,
Nov 10 2016
Does Google Chrome have the same problem? If yes, can you get a crash report id? https://www.chromium.org/for-testers/bug-reporting-guidelines/reporting-crash-bug Who build the Chromium browser you are running?
,
Nov 10 2016
> Does Google Chrome have the same problem? Yes - just confirmed on chrome from the official google repo on the following versions: * stable: 54.0.2840.90-1 * beta: 55.0.2883.35-1 * unstable: 56.0.2906.0-1 > If yes, can you get a crash report id? Crash ID: crash/3ba82e6700000000 > Who build the Chromium browser you are running? Chad MILLER <chad.miller@canonical.com> [1] [1]: from the changelog: chromium-browser (53.0.2785.143-0ubuntu0.16.04.1.1254) xenial-security; urgency=medium * Upstream release 53.0.2785.143: - CVE-2016-5177: Use after free in V8. - CVE-2016-5178: Various fixes from internal audits, fuzzing and other initiatives. * Upstream release 53.0.2785.113: - CVE-2016-5170: Use after free in Blink. - CVE-2016-5171: Use after free in Blink. - CVE-2016-5172: Arbitrary Memory Read in v8. - CVE-2016-5173: Extension resource access. - CVE-2016-5174: Popup not correctly suppressed. - CVE-2016-5175: Various fixes from internal audits, fuzzing and other initiatives. * debian/rules: Use gold ld to link. * debian/rules: Kill delete-null-pointer-checks. In the javascript engine, we can not assume a memory access to address zero always results in a trap. * debian/patches/gsettings-display-scaling, debian/patches/display-scaling-default-value, reenable DPI scaling taken from dconf. * debian/rules: explicitly set target arch for arm64. * debian/control, debian/rules: re-add -dbg transitional packages. * Upstream release 53.0.2785.89: - CVE-2016-5147: Universal XSS in Blink. - CVE-2016-5148: Universal XSS in Blink. - CVE-2016-5149: Script injection in extensions. - CVE-2016-5150: Use after free in Blink. - CVE-2016-5151: Use after free in PDFium. - CVE-2016-5152: Heap overflow in PDFium. - CVE-2016-5153: Use after destruction in Blink. - CVE-2016-5154: Heap overflow in PDFium. - CVE-2016-5155: Address bar spoofing. - CVE-2016-5156: Use after free in event bindings. - CVE-2016-5157: Heap overflow in PDFium. - CVE-2016-5158: Heap overflow in PDFium. - CVE-2016-5159: Heap overflow in PDFium. - CVE-2016-5161: Type confusion in Blink. - CVE-2016-5162: Extensions web accessible resources bypass. - CVE-2016-5163: Address bar spoofing. - CVE-2016-5164: Universal XSS using DevTools. - CVE-2016-5165: Script injection in DevTools. - CVE-2016-5166: SMB Relay Attack via Save Page As. - CVE-2016-5160: Extensions web accessible resources bypass. - CVE-2016-5167: Various fixes from internal audits, fuzzing and other initiatives. * debian/patches/cups-include-deprecated-ppd, debian/rules: include cups functions. * debian/rules, debian/control: Force using gcc-5 compiler. * Use system libraries for expat, speex, zlib, opus, png, jpeg. * Also build for arm64 architecture. * Don't compile in cups support by default on all architectures. * debian/control: remvove build-dep on clang. * debian/patches/linux45-madvfree: If MADV_FREE is not defined, do not allow it in sandbox filter. Also, undefine it so we don't use MADV_FREE and thereby depend on it at runtime. * debian/rules: Use gold ld to link. * debian/rules: Kill delete-null-pointer-checks. In the javascript engine, we can not assume a memory access to address zero always results in a trap. * debian/patches/series, debian/rules: Re-enable widevine component. -- Chad MILLER <chad.miller@canonical.com> Fri, 16 Sep 2016 12:56:44 -0400
,
Nov 10 2016
CCing some people who might know about this. The stacktrace from the Google Chrome crash is below:
#0 delegate (this=0x0) at ../../components/web_modal/web_contents_modal_dialog_manager.h:30
#1 CreateWebModalDialogViews (web_contents=0x37cd4a4daa00, dialog=<optimized out>) at ../../components/constrained_window/constrained_window_views.cc:194
#2 constrained_window::ShowWebModalDialogViews (dialog=0x37cd4a6f7f90, initiator_web_contents=<optimized out>)
at ../../components/constrained_window/constrained_window_views.cc:162
#3 0x00005569a0699334 in LoginHandlerViews::BuildViewImpl (this=0x37cd4a6f7c00, authority=..., explanation=..., login_model_data=<optimized out>)
at ../../chrome/browser/ui/views/login_handler_views.cc:121
#4 0x00005569a04c0395 in BuildViewWithoutPasswordManager (this=0x37cd4a6f7c00, authority=..., explanation=...) at ../../chrome/browser/ui/login/login_handler.cc:151
#5 LoginHandler::ShowLoginPrompt (request_url=..., auth_info=0x37cd4bf4fac0, handler=0x37cd4a6f7c00) at ../../chrome/browser/ui/login/login_handler.cc:550
#6 0x000055699e520bd0 in content::InterstitialPageImpl::OnDomOperationResponse (this=0x37cd4bf5a900, json_string=...)
at ../../content/browser/frame_host/interstitial_page_impl.cc:861
#7 0x000055699e520ca0 in DispatchToMethodImpl<content::InterstitialPageImpl*, void (content::InterstitialPageImpl::*)(std::basic_string<char> const&), std::tuple<std::basic_string<char> > const&, 0> (method=<optimized out>, obj=<optimized out>, args=...) at ../../base/tuple.h:144
#8 DispatchToMethod<content::InterstitialPageImpl*, void (content::InterstitialPageImpl::*)(std::basic_string<char> const&), std::tuple<std::basic_string<char> > const&> (
obj=<optimized out>, method=<optimized out>, args=...) at ../../base/tuple.h:151
#9 DispatchToMethod<content::InterstitialPageImpl, void (content::InterstitialPageImpl::*)(std::basic_string<char> const&), void, std::tuple<std::basic_string<char> > > (
obj=<optimized out>, method=<optimized out>, tuple=...) at ../../ipc/ipc_message_templates.h:26
#10 IPC::MessageT<FrameHostMsg_DomOperationResponse_Meta, std::tuple<std::string>, void>::Dispatch<content::InterstitialPageImpl, content::InterstitialPageImpl, void, void (content::InterstitialPageImpl::*)(std::string const&)> (msg=0x37cd4bc659b0, obj=<optimized out>, sender=<optimized out>, parameter=<optimized out>, func=<optimized out>)
at ../../ipc/ipc_message_templates.h:121
#11 0x000055699e5201f1 in content::InterstitialPageImpl::OnMessageReceived (this=0x37cd4bf5a900, render_frame_host=<optimized out>, message=...)
at ../../content/browser/frame_host/interstitial_page_impl.cc:361
,
Nov 10 2016
I have run into a similar issue before (crbug.com/649191) where the solution is to invoke CreateWebModalDialogViews with the top-level WebContents of the given WebContents because only the top-level WC is guaranteed to have a WebContentsModalDialogManager. My issue was using a different code path though. It looks like the stack trace in c#5 is already using the top-level WebContents, but we are still getting a nullptr WebContentsModalDialogManager. Why is that?
,
Nov 10 2016
> It looks like the stack trace in c#5 is already using the top-level > WebContents, but we are still getting a nullptr > WebContentsModalDialogManager. Why is that? I've observed some symptoms that may help narrow it down: Scenario 1: * browse to a http/s page, * authenticate against the proxy (*before* attempting to sign in to chrome) * sign in via the title bar button -> Segfault Scenario 2: * browse to chrome://chrome-signin/?access_point=0&reason=0 * authenticate against the proxy * sign in via the in page form -> page hangs with a spinning dialog, or immediately returns failure via overlay in the top right corner Scenario 3: * browse to chrome://chrome-signin/?access_point=0&reason=0 * authenticate against the proxy * browse to a http/s page, * authenticate against the proxy (again!) * sign in via the in page form -> success (usually...) Scenario 4: * browse to chrome://chrome-signin/?access_point=0&reason=0 * authenticate against the proxy * browse to a http/s page, * authenticate against the proxy (again!) * sign in via the title bar button -> overlay dialog appears, and login succeeds The key point is that my successful proxy authentication token for the chrome:// url is ignored when I then try to browse a http/s url - therefore I have to authenticate against the proxy again.
,
Jul 27 2017
This problem also occurs on the latest version of Chrome on Microsoft Windows. I have reproduced it in older versions of Chrome too, it does not appear to be a new issue.
,
Jul 27 2017
,
Sep 1 2017
,
Sep 20 2017
Merged into a bug I don't have permission to see :( Regardless, there's some good news in 61.0.3163.79 - no more segfault! |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by bernard_...@debortoli.com.au
, Nov 9 2016