GNOME Bugzilla – Bug 752738
(CVE-2017-1000025) Password manager allows HTTP sites to access passwords saved on HTTPS sites
Last modified: 2017-07-08 14:54:54 UTC
The page http://whatever.com has access to saved passwords of https://whatever.com. This was a very bad idea: it makes it easy to intercept passwords stored on secure websites, especially since we don't require any user interaction to fill in the password. Consider the following scenario: 1) User visits http://whatever.com and is redirected to https://whatever.com. 2) User sees HTTPS, thinks "safe," enters password, saves it in the password manager. 3) User later visits http://whatever.com and is not redirected to https://whatever.com because an attacker has intercepted the connection. 4) Attacker triggers password autofill automatically (see also bug #752737) via JS and sends the password to some server. The user might possibly notice that the site is not HTTPS, but has no reason to think the password has been compromised: after all, it wasn't submitted to the page yet. That's safe, right? (Of course a more realistic user would go ahead and submit the password to the insecure page anyway.)
Note that an attacker can then enumerate passwords from an arbitrary set of interesting websites by using simple redirections. And since Epiphany does not support HSTS, websites can do nothing to prevent users from being redirected to attacker-controlled pages. Unfortunately any fix for this issue causes some very awkward migration issues. If anyone wants to help with password migration, please get in touch.
The following fixes have been pushed: 1320bb1 Add profile migrator to migrate insecure passwords f7823c4 form-auth-data: fix function name typo fae5249 form-auth: Store passwords for security origins, not hosts
Created attachment 344726 [details] [review] Add profile migrator to migrate insecure passwords All previously-saved passwords will now only be available to https:// origins. Users will have to manually enter their passwords once again in order to save them separately for an insecure origin.
Created attachment 344728 [details] [review] form-auth-data: fix function name typo
Created attachment 344729 [details] [review] form-auth: Store passwords for security origins, not hosts This prevents an active MITM attacker from enumerating all your saved passwords. The attacker will now only be able to access passwords saved on http:// sites. That's by design, though; users are now warned when focusing insecure password forms and should think twice before saving such passwords. Unfortunately this does introduce a migration issue, in that no previously-saved passwords will be available on https:// websites anymore, and all previously-saved passwords will still be enumerable by attackers. I'm not sure how to handle migration. We might be able to handle it nicely by using the history service to guess whether a password should be migrated from http:// to https://, but that is not a simple project.
The following fix has been pushed: ffbbbfe Fix impedance mismatch between web extension and form auth data cache
Created attachment 344757 [details] [review] Fix impedance mismatch between web extension and form auth data cache Using just host is not sufficient, we need to have protocol and port as well for matching based on security origin to work properly. Unfortunately the existing code here was full of subtle errors: the parameters named "uri" were actually passed hostnames from the web extension, and not URIs at all. The code only worked as long as that assumption held, but I broke it because I expected the URI parameters to actually contain URIs. So fix this. Really pass URIs and not hostnames, and properly convert them to security origins. Thanks to Hussam for reporting this bug so quickly after it was introduced. (As well as lots of other bugs in the past that I've rarely credited him for in commit messages.)
The following fixes have been pushed: 71d0b0a form-auth-data: Properly normalize URI when accessing secret service f90ce8b form-auth-data: Add debugging statements 7d2448d debug: Update comment
Created attachment 344825 [details] [review] form-auth-data: Properly normalize URI when accessing secret service I've mishandled this issue pretty badly. Incredibly, my previous patch, which was intended to ensure we always normalize URIs to security origins when working with form auth data, only fixed use of the form auth data cache. It didn't actually fix any use of the secret service itself. Fix that. This commit notably removes support for mailman passwords, which is making the code way too complicated and conflicts with the goal of storing only security origins and not full URIs in the secret service. Note: this normalization is way better than what we were doing before. In particular, it incidentally fixes odd bugs like the URI framgment, even the empty fragment #, being sufficient to trick our password manager into storing separate passwords, so this should also make the password filling significantly more reliable than it used to be. (Unless you need per-URI passwords without a username, i.e. mailman passwords, in which case you're just out of luck, sorry!)
Created attachment 344826 [details] [review] form-auth-data: Add debugging statements
Created attachment 344827 [details] [review] debug: Update comment
Created attachment 344831 [details] [review] Do not run new migrator if the main profile has been migrated This is ephy *profile* migrator. It runs on a per-profile basis. i.e. each web app runs migrators separately. So this migration step could run once for a profile dir, then again far in the future when an old web app is opened. But passwords are global state, not stored in the profile dir, and we want to run this migration only once. This is tricky to fix, but it's easier if we relax the constraint to "never run this migrator if it has been run already for the default profile dir." That's because we don't really care if a couple web app passwords get converted from insecure to secure, which is not a big problem and indicates the user probably never uses Epiphany except for web apps anyway. We just don't want all the user's passwords to get converted mysteriously because he happens to open a web app. So check the migration version for the default profile dir and abort if this migrator has already run there. This way we avoid adding a new flag file to clutter the profile dir just to check if this migrator has run.
Comment on attachment 344831 [details] [review] Do not run new migrator if the main profile has been migrated Ok, we should warn people using only web apps to run ephy once, or to run the migrator manually for the default dir. I wonder if we could run the default dir migrator from web apps, instead of returning early to skip that step, but I guess it could be racy, so this is probably safer.
Comment on attachment 344831 [details] [review] Do not run new migrator if the main profile has been migrated Attachment 344831 [details] pushed as fac43af - Do not run new migrator if the main profile has been migrated
Are there any plans on assigning a CVE for this problem? Per my distribution's policy, I can't issue a security advisory to my users without one.
I requested a CVE via the DWF project a few days ago. I do not know when to expect a response. I am no longer requesting CVEs via Openwall because I have yet to receive a response to my last request, and it has now been over one year. See https://lwn.net/Articles/679315/ and in particular https://lwn.net/Articles/679505/ for details on that. Your distribution may need to adjust its security policy if this situation does not improve. :(
(Note: still no response to my CVE request.)
(In reply to Michael Catanzaro from comment #17) > (Note: still no response to my CVE request.)
Rather than requesting CVEs via the oss-security mailing list, the preferred method is via webform at https://cveform.mitre.org/ Response time has reportedly been pretty good (less than a day).
Our outstanding CVE request is via the DWF project. I am not going to create a duplicate CVE request for this issue. It's just not going to get a CVE anytime soon, I suppose.
(In reply to ejratl@gmail.com from comment #19) > Rather than requesting CVEs via the oss-security mailing list, the preferred > method is via webform at https://cveform.mitre.org/ Response time has > reportedly been pretty good (less than a day). This form now states that open source CVE requests must be made through the DWF project, which is what I already did. Still waiting. Your distribution really must adjust its security policy if it currently requires CVEs to issue security updates. It's not that I have not tried to request a CVE: the CVE request process has just broken down. This is not a new issue, so it should not be surprising to distributions; the LWN article I linked to up above was written over a year ago.
Well good news, I complained [1] and it looks like DWF assigned a bunch of CVEs two weeks ago, but they had not notified the requesters yet. And it also looks like the CVEs don't appear in the MITRE or NVE databases yet. But DWF is a real CNA and it's a real CVE, so... this is CVE-2017-1000025. [1] http://www.openwall.com/lists/oss-security/2017/05/22/5
And yesterday, July 7, I received a notification of the CVE assignment. Only took five months. :)