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

Issue metadata

Status: Duplicate
Merged: issue 453093
Owner: ----
Closed: May 2015
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment
link

Issue 488087: Chrome Extention URL does not allow the user to confirm they are looking at the correct Extention

Reported by h...@downrighttech.com, May 14 2015

Issue description

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

Steps to reproduce the problem:
Scenario A)
1. Install LastPass Extension (for example)
2. Click on the App extension icon to the right of the address bar
3. Without entering a password, click on the login button.
4. When the "Invalid Password" error is displayed, click on Try again
5. Take note of the chrome-extension:// url.

Scenario B)
1. Install LastPass Extension (for example)
2. Click on the App extension icon to the right of the address bar
3. Prove that the URL posted in the address bar is in fact LastPass

What is the expected behavior?
The user should easily be able to confirm that they are entering their potentially sensitive information into the correct extension by viewing the address bar (Scenario A) or some other mechanism (Scenario B).

What went wrong?
In the case of the Lastpass, the user is presented with an extension ID in the address bar of chrome:

chrome-extension://hdokiejnpimakedhajhdlcegeplioahd/login.html

and expected to trust that they are in fact looking at the Lastpass Extension based on the ID (hdokiejnpimakedhajhdlcegeplioahd).

It seems that an extension, perhaps legitimate looking,  could easily impersonate another extension without the user knowing.

For example:

1) The user installs a legitimate application that when restarted causes a page to be displayed that looks like the Lastpass login screen but with a different extension ID:

chrome-extension://hdokiejnpim-HACKED-dlcegeplioahd/login.html

In this case the user might login using the presented page causing their personal information (and potentially OTP) to be exfiltrated in real time.

2) an attacker in a privileged position, placed the browser in developer mode, and installs an extension crafted to look like the Lastpass extension and disabled or hides the original extension or button.  This allows the attacker to capture the users personal information without the using being aware.

Obviously in example 2 the attacker with physical access could just easily install some other means of collecting the user's information (keylogger...) however this might be risky and allow for easy detection. The real issue is that the user has no way of confirming with the browser that they are in fact looking at (and trusting) the correct extension.

Suggestions:
1) Force chrome-extension:// urls to be signed or encrypted/authenticated by TLS
2) Display a confirmed extension ID in the URL eg. chrome-extension://lastpass/login.html
3) Force a different visual look for developement mode extensions (though I thought this was the case)

WebStore page: https://chrome.google.com/webstore/detail/lastpass-free-password-ma/hdokiejnpimakedhajhdlcegeplioahd

Did this work before? N/A 

Chrome version: 42.0.2311.135  Channel: n/a
OS Version: OS X 10.9.5
Flash Version: Shockwave Flash 17.0 r0

Firefox displays extensions with a common name:
chrome://lastpass/content/home2.xul

Safari does not show a URL
 

Comment 1 by kavvaru@chromium.org, May 15 2015

Cc: kavvaru@chromium.org
Labels: -OS-Mac OS-All M-44
Status: Untriaged
hoss@ Thanks for reporting.

Tested the issue on windows 7, Linux Ubuntu 14.04 and Mac 10.10.3 using chrome latest stable 42.0.2311.152 and canary 44.0.2401.0 with the below steps

1. Install LastPass Extension 
2. Click on the App extension icon to the right of the address bar
3. Without entering a password, click on the login button.
4. When the "Invalid Password" error is displayed, click on Try again
5. copied the URL "chrome-extension://hdokiejnpimakedhajhdlcegeplioahd/login.html

Able to reproduce the issue on ALL OS. This is non regression since from M35.
Marking it as Untriged to get more inputs from Dev team.

Comment 2 by kalman@chromium.org, May 15 2015

Mergedinto: 453093
Status: Duplicate
I agree that we should better attribute extensions to their URLs, though note that any extension which is determined enough to phish in this way is probably determined enough to have a convincing sounding name.

I don't understand your point (1), TLS has nothing to do with this, and I also don't really understand (3) why developer mode extensions are special in any way. (2) I already filed a bug on so duping it to that.

Comment 3 by h...@downrighttech.com, May 15 2015

To point 1, (As you noted in 453093) I used the wrong term, For example if I go to https://lastpass.com I see an EV cert, if the extension could be pinned somehow so that only the downloaded extension would show a green lock to confirm to the user that they are looking at a the same app the downloaded or updated. Perhaps code signing or hashing the extension and pulling the cert or hash from the store.

3) Ok, I was sure in an older version of chrome the user was informed of being in dev mode. This allows an end user (who probably doesn't know what dev mode is) to know or at least suspect that something might be wrong.

2) not needed if #453093 is implemented

Funny I searched and did not notice you submission.

Sign in to add a comment