Ghosts of Extensions Control Proxy Settings
Reported by
ilyaigpe...@gmail.com,
Jan 23 2017
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 Steps to reproduce the problem: 1. Install several extensions that change `chrome.settings.proxy` several times passing control to each other. 2. Delete all extensions. 3. In Chromium settings find "Your network proxy settings are being managed by an extension." 4. Notice that Chromium doesn't tell which extension controls proxy. 5. Notice that some extension controls proxy despite all extensions were deleted. What is the expected behavior? 1. "Your network proxy settings are being managed by an extension." in Chormium settings MUST always point which exactly extension controls proxy. 2. If you delete all extensions then proxy settings MUST be reset to defaults. What went wrong? 1. Chromium says that proxy is controlled by an extension, but doesn't tell which extension exactly. 2. Even if all extensions are removed, proxy settings are not rollbacked to defaults. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 55.0.2883.87 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 24.0 r0 I attach screencast to facilitate understanding. Unfortunately, I can't offer exact steps to reproduce this bug yet.
,
Jan 23 2017
I haven't tried these steps, but I'll do it later: The idea is that after clearing settings previous value is restored, but what if extension responsible for previous value was deleted long ago? 1. Install extension that sets PAC script via data property. 2. Install second extension that does the same and overrides previous settings. 3. Delete first extension. 4. Clear settings via second extension. 5. Delete second extension. 6. Notice that proxy configs are not restored to defaults.
,
Jan 23 2017
,
Jan 24 2017
,
Jan 24 2017
Could you please help with the sample Extensions to triage further from Chrome TE side.
,
Jan 25 2017
I've tried following the steps from comment #2. Unfortunately they don't reproduce the bug. I attach a sample extension that allows getting/setting/clearing proxy settings, but it's useless unless you know the steps that reproduce the bug. To see outputs of extension, open console of its background page: 1. open chrome://extensions 2. tick "Developer mode" 3. under extension click "background page" 4. select tab "Console" and don't close it 5. open popup by clicking icon with "M" and click a button 6. see outputs in console.
,
Feb 1 2017
Thank you for providing more feedback. Adding requester "durga.behera@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 13 2017
Cleaning up "Needs-Review" label as we are not using this label for triage. Ref bug 684919
,
Mar 13 2017
,
Mar 17 2017
I'm not sure if this is related but I was seeing odd behavior related to extensions and proxies. Around March 4th, a dev account was compromised and pushed a hacked version of the extension that started asking for permission to change the proxy settings. I immediately pushed a corrected version of the extension, but unfortunately some users did receive the hacked version before the new code was deployed. Oddly today some of my users are saying that they are being prompted by chrome in a dialog box that my extension is trying to change their proxy settings. Between testing on Chrome for Windows 10, Chrome for Mac (56) and Chrome Canary for Mac (59), I was only able to get the dialog to appear once for the Chrome for Mac (56). Now I can't reproduce again at all. I never actually saw evidence that the proxies were actually being changed or that my code had been compromised again in any way. According to the chrome://extensions page, the extension still didn't actually have any unexpected permissions granted to it. My initial theory was that maybe internally chrome had a bug that resulted in a long delay before the original proxy permissions warning was delivered. In other words, I think the warning was just a false alarm. But then again, because I am unable to prove this at the network level myself so I remain open-minded. Of course, I'll continue to look into this on my end, but I'm eager to hear back on this thread as this issue could potentially be a security risk for my users.
,
Mar 17 2017
I forgot to mention that I think the reason why my Chrome 56 browser showed the issue is because that one as far as I remember is the only one that had had the original hacked extension installed. The screenshot I just sent was submitted by a user in a bug report. It appears that she was using a windows computer.
,
Mar 17 2017
I just noticed this in my chrome settings. However, if I examine the extension code itself as downloaded into the chrome directory ("~/Library/Application Support/Google/Chrome/Default/Extensions/[extension_id]/[extension_version]"), I can see that it's the correct version number and that it doesn't even ask for permission to change any proxy settings.
This image would indicate that the bug is not related to delayed notifications but is related to how permissions are stored and passed around in internal chrome settings.
,
Mar 19 2018
Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by ilyaigpe...@gmail.com
, Jan 23 20175.9 MB
5.9 MB View Download