Background for 4.6.1 Security changes
The release notes for 4.6.1 include the statement:
Improves verification and authentication of communication with the 1Password browser extension to address an issue reported by Tavis Ormandy of Google Project Zero. Users should update promptly.
I would like to explain a bit more about what that is. I expect that most people reading this will be unaware that some people have been waiting eagerly since the beginning of August to know what security issue Tavis Ormandy reported to us. But those who have been waiting have been waiting very eagerly for the explanation.
The vulnerability that Tavis Ormandy of Google's Project Zero reported to us at the beginning of August could only be exploited locally on Windows systems by another user of that same machine. A successful exploit of it on those systems would have led to capture of many of a victim's website usernames and passwords. For that portion of 1Password users who this might have affected, this was a serious vulnerability. We have no reason to believe that this vulnerability was ever exploited.
The solution is what everyone is seeing. We now require the user to do a one-time approval of each browser extension and after that is set up the browser extension and 1Password Agent will share a secret that they will use to prove that each message and request between the browser extension and 1P Agent involves a previously approved extension.
What does this solve?
We've long had measures in place to prevent some user, Patty let's say, from running a fake browser extension that could talk to Molly's 1Password Agent. Indeed, more than a year ago we wrote about some of the challenges in designing those measures.
One of those measures involves the Agent trying to figure out who the "owner" of the other end of the connection is. When Molly is running 1Password Agent and a browser extension tries to talk to Agent, Agent will ask the operating system (Windows or Mac) about the process at the other end of the connection. If Agent is owned by Molly, it should only talk to extensions that are owned by Agent. It should refuse to talk to an extension that is running in a process owned by Patty.
The details of what the Agent has to ask the operating system and what the operating system can answer depend on – you guessed it – the operating system. On Mac we could get the effective user ID of the other end of the connection, while on Windows we could get something called the SessionID. We compared whether the SessionIDs matched. Unfortunately, as Tavis pointed out to us, this turned out to be a less reliable way to determine the owner of the process than we needed. It turns out that a different user on the same Windows machine can create a process under a SessionID that is the same as Molly's.
A bit about browser extension and Agent communication
One of our design principles is to keep as few secrets in the browser extension as possible. It is 1Password Agent (or "mini" on the Mac, or "Helper" for 1Password 6 for Windows) that actually handles the secrets. This is because web browsers are inherently hostile environments.
So when you, say, use control-\ (or command-\ on Mac), Agent will ask the 1Password browser extension about the site it is on. The extension will tell Agent, and Agent might say, "I know how to fill things on that site, send me details about the page and I will tell you how to fill it". The extension will tell Agent the details about the page, and Agent will respond with filling instructions including the username and password to be filled in. There are also times when the extension can start this conversation (when you click on the 1Password icon within the browser, for example.) So that means that the extension can ask Agent, "Hey, how do I fill this page?" and Agent will respond with the filling instructions, including username and password.
So because Agent is happy to tell the browser extension the username and password for any site the extension knows about, it is important that Agent is only talking to a bona fide 1Password extension. Ensuring this is tricky, and we use a number of mechanisms to deal with this. Tavis showed us that one of the mechanisms that we used wasn't as reliable as we'd previously thought.
Fixing a hole where pain gets in
The threat that Tavis pointed out is from another unprivileged user on the same system. And so our new defense is against that threat. Our other defenses remain in place. While we could have tried to see if there were ways to tweak the SessionID check (something we still may do), we started working on a defense against this threat that isn't tied to the finer details of a specific exploit. A more general defense is better, as it would not only defend against the very specific attack in question but can defend against a larger class of potential attacks that might be developed in the future.
When you authorize a new browser extension, it and Agent will pick a long term secret that each will store. Every time they connect after that, they will use their copy of that stored secret to prove to each other that they have that secret. They do this in an exchange that is kind of like, "Hey, here is a challenge for you that you should be able to complete only if you know the same secret I use to construct the challenge." That way they can each prove to the other that they know the shared secret without actually revealing the secret to each other. The only time the secret is transmitted (from the extension to the Agent/mini/Helper) is when you first authorize the extension.
It is not just that every connection between the extension and Helper is authenticated this way, but each message they send to each other is encrypted and authenticated using an Encrypt-then-MAC scheme.
What it doesn't do
It should be made clear that this fix does not defend against an attacker who can read Molly's files. Both Helper and the extension store their shared secret long term and this can be read from the disks. This is fine because this measure is designed to defend against the attacker who is another user on the same system.
We have considered doing something like what we have done now several times over the past few years, but we always felt that it was unnecessary because it would only defend against someone who could not read the target's disk. Indeed, I am very much on record for saying that such a move would be pointless. But now we more clearly realize that it makes sense to address the threat of an unprivileged user distinct from the target as a threat to be addressed in its own right. Of course our SessionID check was an attempt at that, but we now take more robust measures.
Comments
-
Did AppData\Local\AgileBits\OPX4.auth always exist?
After the update on Windows 10 I received a notification about encrypted files asking me to backup the key. I don't have any encrypted files on Windows. Looking at cipher the only file listed is this AgileBits file.
This notification scared me that I had randsware. Now I'm thinking its 1Password.
0 -
AppData\Local\AgileBits\OPX4.authis us.That's the file in which the agent/helper stores the secrets that they get from the browser extension when you first
authoriseauthorize an extension. You can think of it as a username and password for the extension.Note that file will be readable by anyone who can read your files on your machine. So this only defends against other users on the same machine. Each browser (or profile within a browser) will also be storing those. So because the same secret is stored in each browser, there is no point in hashing these.
0 -
Now that you mention it, there was a prompt for authorization that I never seen before. So that's the cause of the Windows prompt. What was that authorization? Was that from Chrome making sure 1Password was okay to use? I never had that occur before on an update.
0 -
Yes, @alamarco. 1Password was asking for your approval to allow the browser extension (in your case in Chrome) to talk to it.
0 -
Thanks for clearing that up. Definitely a less stress knowing it's not ransomsare.
0 -
You are very welcome, @alamarco.
This is all sort of tricky to talk about because there have been some people waiting two months to find out what Tavis Ormandy discovered. While of course this issue was a serious one for users in the relevant environments, it probably is less serious than many people feared. But I am trying to address those people in this discussion. Let me tag some of them here: @McGarnacle, @cmroanirgo, @Damnatus who all posted in Topics -> Lounge: 3rd party reviews
On the other hand, I also need to address 1Password users who were unaware that the existence of some bug or other had been publicly announced a two months back and who aren't aware of Tavis Ormandy's outstanding record of finding serious issues in security software.
And to make things more tricky, we needed to test a visible change in behavior (the initial authorization of the extension) without giving away enough details of the actual vulnerability until we had a full fix in place for everyone. So it was very very difficult for us and for our beta testers for us to be so quiet about that the change was for. But we didn't want to draw attention to the fact that it mostly protects against other users on the same local system and that our focus was on Windows. Someone who figured that out would be in a decent position to find what Tavis originally reported to us. The fact that the first beta testers to see the new behavior were on Mac wasn't a deliberate act of misdirection, but it may have worked out that way anyway.
We really like telling people what is going on and why we do things. And we expect that people want to know. But we've had to be circumspect until now. And because our fix involved changes in how the extension and the helper talk to each other along with adding in some additional user interaction, it took time. So we've had to be quite about this for a long time and then vague about what was showing up in betas. So I am pleased to be able to take questions and answer them fully and clearly.
0 -
@jpgoldberg. Thank you for taking the time to explicitly loop me in to this discussion. The handling of the report and it's ultimate disclosure have been exceedingly professional at all times and I must congratulate you and your team on the problem of security management. Once again AgileBits have shown themselves worthy of commendation.
0 -
Thanks @cmroanirgo!
0 -
@jpgoldberg. Once again, thank you for the response on this. However, even as you are planning on releasing something similar for macOS, have you considered a more radical overhaul?
E.g. at this years PasswordsCon, where you presented, Nick Sullivan from CloudFlare presented on PAL: Permissive Access Link. While the extension may not need to live in a container, the patterns for permissioning, validating, and spinning up another process seem like a promising solution, that would work on macOS, Windows, etc.
Thoughts? At the moment, I am leaning towards completely disabling 1Password mini and the browser extension, for fear of all my passwords being sucked out by an app, even if from the App Store.
Regards,
SS0 -
Thanks @steven1. I loved the presentation on PAL, but I'm not entirely sure how it is something we could get running on a users operating system. It is something that the operating system would need to build in deeply and then the browsers in which the extension runs would need to also somehow handle this so that different extensions have different permission management.
Perhaps I have misunderstood what you are suggestion.
0 -
Like alamarco I had a "oh crap, ransomware" moment when Windows 8.1 gave me a "encrypting file system" notification. It definitely would have eased my mind if I was warned of this beforehand as the release notes make no mention of a new certificate being generated or whether this key should be backed up. I had to manually check the certificate store and run the "cipher /u /n" command to be sure it wasn't malicious.
I presume backing up the key isn't necessary since a loss would just trigger the extension authorization prompt again.
0 -
@chilgart: I'm sorry for the confusion. The recent security changes with 1Password's browser extension authentication are not related to what you seem to be describing. I've only heard of that once before, and it was in the context of "security" software performing a person-in-the-middle attack on users with a self-signed certificate.
1Password doesn't modify your browser's certificate store; it only shares a secret with its extension after you verify that the codes match, which it then stores in its own AppData folder. So this only applies to 1Password if you're getting this message for that file being created to validate the browser connection. I hope that clears things up! :)
0 -
Hi @chilgart,
You are the second person (that I've seen) to comment about 1Password triggering some file system encryption. And that doesn't make a lot of sense to me.
But, this version of 1Password will create a file that may look like an encrypted file. It is
AppData\Local\AgileBits\OPX4.authand that seems to be getting something to trigger alerts. So could the message you saw have been "encrypted file on system" instead of "encrypted file system"?0 -
@jpgoldberg It is most certainly the "Encrypting File System" Windows service. The notification is gone now but I found the exact same pop-up message through Google Images below. This also happened when I updated 1Password on Windows 7. The second screenshot is my cert store and confirmation that OPX4.auth was created at the exact same time as the cert. EFS apparently doesn't like generating private keys without backing them up.
0 -
@chilgart: Thanks for clarifying. I'm sorry for the confusion! 1Password for Windows uses the Windows EFS for some temporary data, but you won't see a message about this unless you haven't ever backed up your keys. You can find more information here. And while the data 1Password stores in EFS isn't something you need to worry about backing up, you should definitely backup your keys as Windows suggests in case there is any other data on your PC which you might need to access in an emergency.
0 -
-
The Encrypting File System (EFS) isn't often used and is only in Pro versions of Windows. When it is used it's often on a domain where keys can be backed up with recovery agents in Active Directory, not in standalone systems. You can right-click files on versions with support for EFS, go to Properties, click Advanced or Details button (from memory) and check the Encrypt File checkbox to manually encrypt a file. It uses an automatically generated key that's derived from your Windows password. This key (a certificate actually) needs to be backed up if you ever want to decrypt those files! If you forcefully reset your Windows password (from another Admin account or an offline password reset tool), you'll lose access to these files as well (in fact if you reset another user's password, this is what the big warning is about). If you look at this 1Password file's properties I assume this checkbox will already be checked (I haven't looked, I'm typing this on my phone).
Most people won't have any of these files because it's not a commonly used encryption method, as it's not super user friendly to back up or manage the files with this method unless you're implementing it across an Active Directory domain and then it takes much planning. The 1Password file using this type of encryption triggers the OS ago prompt to backup the key because it either didn't exist before (mostly unused, remember) or wasn't used if it did. But it's being good and telling you to back up the key--except most people won't know how to, EFS and the warnings were written before ransomware was popular (it was in XP/2003 if not before!), and 1Password appears to be using it to back up a file that doesn't matter--if you lose access to it, just delete it and reauthorize your browser extensions (I assume). But Windows will still warn you about backing up the key, I saw this myself on Win 10 Pro.
Since I believe the encryption certificate is per-user (see tied to password/account above), one cool benefit of this is other users on the computer (even if local admins) likely can't access the file without the user's actual password for their account, even if they override file system permissions. Though I haven't tested this or anything.
Good to know the mechanisms behind the new change which I feel is a good step forward in security, thanks! And happy to finally know more about Tavis' report. If that's all he found either he didn't look hard or he quit early, or the software is very secure. Possibly all of the above :-)
0 -
The Encrypting File System (EFS) isn't often used and is only in Pro versions of Windows.
@dszp: Excellent point. While Windows 8 and 10 simplified things considerably by reducing the number of "editions", the "Home" version apparently still doesn't support EFS. Less confusing than Windows 7 in that regard, but still not simple.
When it is used it's often on a domain where keys can be backed up with recovery agents in Active Directory, not in standalone systems. You can right-click files on versions with support for EFS, go to Properties, click Advanced or Details button (from memory) and check the Encrypt File checkbox to manually encrypt a file. It uses an automatically generated key that's derived from your Windows password. This key (a certificate actually) needs to be backed up if you ever want to decrypt those files! If you forcefully reset your Windows password (from another Admin account or an offline password reset tool), you'll lose access to these files as well (in fact if you reset another user's password, this is what the big warning is about).
All of this is, unfortunately, very much targeted at enterprise users, so it's a bit obtuse. But I'm glad at least that Windows has this feature. If we were still stuck with the security model of Windows XP in 2016, we'd be in real trouble. It's a step in the right direction.
If you look at this 1Password file's properties I assume this checkbox will already be checked (I haven't looked, I'm typing this on my phone).
Indeed. Windows File Explorer also displays a graphical "padlock" icon on encrypted files, which can save you a trip to Properties > Advanced.
Most people won't have any of these files because it's not a commonly used encryption method, as it's not super user friendly to back up or manage the files with this method unless you're implementing it across an Active Directory domain and then it takes much planning. The 1Password file using this type of encryption triggers the OS ago prompt to backup the key because it either didn't exist before (mostly unused, remember) or wasn't used if it did.
But it's being good and telling you to back up the key--except most people won't know how to, EFS and the warnings were written before ransomware was popular (it was in XP/2003 if not before!), and 1Password appears to be using it to back up a file that doesn't matter--if you lose access to it, just delete it and reauthorize your browser extensions (I assume). But Windows will still warn you about backing up the key, I saw this myself on Win 10 Pro.I think you're right that in most cases it doesn't matter, but it's entirely possible that someone set the EFS property on other files previously and just dismissed the prompt to backup the key. Not a great user experience, but it's good at least that Windows prompts the user.
Since I believe the encryption certificate is per-user (see tied to password/account above), one cool benefit of this is other users on the computer (even if local admins) likely can't access the file without the user's actual password for their account, even if they override file system permissions. Though I haven't tested this or anything.
Exactly. That's just the thing we're trying to protect against with this: attacks from other user accounts — either local or remote. But you're right that there are some complexities to this due to the Windows licensing model.
Good to know the mechanisms behind the new change which I feel is a good step forward in security, thanks! And happy to finally know more about Tavis' report. If that's all he found either he didn't look hard or he quit early, or the software is very secure. Possibly all of the above :-)
I definitely got the impression that he put a lot of time and effort into it. While one man can't be expected to single-handedly find vulnerabilities in every product out there (it takes a community), we similarly put a lot of time and effort into making 1Password secure. And while the "pins and needles" part of this particular episode is over, security is very much a process. So we'll keep plugging away. :)
0 -
Was everything addressed?
0 -
Hi @tommyent,
The specific threat that Tavis reported to us has been fully addressed.
But Tavis appears to be unhappy about more than just the specific issue and threat that he reported to us. As I've stated, we have a bunch of different tests and checks to ensure that a malicious process running on your machine doesn't get away with pretending to be the 1Password browser extension when talking to 1Password Agent/Helper. The difficulty is that each of those tests and checks is fallible on its own. And so it is easy to point out flaws in any individual test.
If you look at the particular attack Tavis pointed out (and which has been addressed) it is an attack that is limited to some very specific circumstances. And it may turn out that there are other circumstances of a malicious process running on the local computer which can lead to something defeating or side-stepping all of the tests we have now, all of our old ones, plus what was introduced in 4.6.1.
When we originally decided to use a localhost WebSocket we were aware that this sort of mutual authentication was going to be very difficult. But we considered it the right security choice when confronted with the alternative to doing everything in the browser. We consider the web browser itself a hostile environment, and so for security (among other reasons) we moved most of what 1Password does for filling and decryption out of the browser. We knew that our choice would mean that we would have difficulties locking our interprocess communication on local hosts, but we felt (and continue to feel) that that puts us in a much better position that having to fend off attacks coming from malicious web pages.
In general we consider remote attacks more worrisome than local ones; so if we had to choose a front on which to have to have a bunch of messy ad-hoc defenses we prefer that front to on the local machine instead of be malicious web pages and the Internet as a whole. I believe that we made the right choice. I would much rather be talking about potential flaws in a series of messy tests that require a malicious process running on your own machine than to be having the same conversation about tests defending against malicious web pages.
So Tavis and others are perfectly correct to hammer away at these local XPC authentication mechanisms. And if (I don't want to speak for them) they feel that the best attacks on 1Password require malicious processes running on the same machine that 1Password is running on, then that is very good news indeed.
0
