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

Issue 772991 link

Starred by 2 users

Issue metadata

Status: Duplicate
Merged: issue 610832
Owner: ----
Closed: Oct 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Chrome extension process does not exit when Profile using extension is closed

Reported by sne...@gmail.com, Oct 9 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36

Steps to reproduce the problem:
1. Install configure addon to one chrome profile.  Be sure it attempts to sync locally on 127.0.0.1:8080
2. Switch to or create a new profile
3. Make sure that the profile with the addon is closed.
4. Listen for requests on 127.0.0.1:8080 -- they will look like:

[404]: /api?output=json&mode=queue&limit=5 - No such file or directory
[404]: /api?output=json&mode=history&limit=10 - No such file or directory

What is the expected behavior?
The addon should not be active.  It should not be able to make requests or receive responses.

What went wrong?
To me this looks like a security hole.  If an addon can make requests to a server when it isn't active, it could potentially be used for malicious reasons.

Did this work before? N/A 

Chrome version: 61.0.3163.100  Channel: stable
OS Version: OS X 10.12.6
Flash Version:
 
Can you point specifically to where you obtained the "Sabnzbd" extension? I see a desktop application, but not a Chrome extension of that name. 

Is the extension you are referring to this one https://chrome.google.com/webstore/detail/sabdrop/bapfpoccgpihfmdaigglhnpkklhacmge ?

Comment 2 by sne...@gmail.com, Oct 9 2017

I'm sorry, I thought the tooltip on the extension gave the correct name, but it is actually the extension SABconnect++ (v0.6.24)

https://chrome.google.com/webstore/detail/sabconnect%20%20/okphadhbbjadcifjplhifajfacbkkbod?hl=en
Components: Platform>Extensions
I can't reproduce this. Can you elaborate on how specifically you "3. Make sure that the profile with the addon is closed."?
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Type-Bug
(removing from security queue since this doesn't look like a vulnerability in chrome itself, but rather a potential privacy issue).

Comment 5 by sne...@gmail.com, Oct 10 2017

Say you have a "work" profile and a "home" profile in Chrome.  On a work computer, the "work" profile will be the primary profile, and the "home" profile is added, but no windows are open to the "home" profile.

My assumption here is that the "home" profile doesn't even assume that Chrome is open, since it doesn't have any active instances running. However, I noticed that I was getting weird requests to my localhost on port 8080 when in my "work" profile.  I happened to have a temporary webserver running on port 8080 and it showed the requests that I listed in my original post.

Is my assumption incorrect?  Can Chrome extensions that shouldn't (well, don't appear to) be loaded, be active?
Cc: sc00335...@techmahindra.com
Labels: Needs-Triage-M61
Cc: devlin@chromium.org
Labels: OS-Windows
Summary: Chrome extension process does not exit when Profile using extension is closed (was: Chrome Add-on Sabnzbd actively sends requests to server when chrome profile it is attached to isn't open)
I have reproduced this in 63.0.3238.0. 

With my Main Profile open, if I open (via the profile switcher) a new Test Profile window that has the extension installed, I see the requests originating from the browser process that's shared between the two profiles. 

When I then close the Test Profile window, I continue to see the requests from the extension that was running in the now-closed profile. If I open the Chrome task manager in the Main Profile window, I still see the extension process is running for the extension which I would've expected to have unloaded.
UnexpectedExtensionProcess.png
24.7 KB View Download
This is a combination of two bugs:
- We don't do any profile cleanup, so even though there are no windows for Profile 1, Profile 1 still fully exists, as does all of its associated data (like extensions).  This is issue 610832.
- We have no mechanism to otherwise fully "close" a profile.  Closing windows is insufficient (sometimes by design, e.g. if you had background-running things).  This is issue 130656.

I think those two issues contain everything in this one.  Does that sound right?
Mergedinto: 610832
Status: Duplicate (was: Unconfirmed)
Thanks!

Sign in to add a comment