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
Labels: -OS-Mac OS-All M-44
Status: Untriaged