1Password inter-process communication: a discussion

Recently, security researcher Luyi Xing of Indiana University at Bloomington and his co-authors released the details of their research revealing security vulnerabilities in Apple’s Mac OS X and iOS that allow “a malicious app to gain unauthorised access to other apps’ sensitive data such as passwords and tokens for iCloud, Mail app and all web passwords stored by Google Chrome.”  It has since been described in the technology press, including an article in the Register with a somewhat hyperbolic title. I should point out that even in the worst case, the attack described does not get at data you have stored in 1Password.

The fact of the matter is that specialized malware can capture some of the information sent by the 1Password browser extension and 1Password mini on the Mac under certain circumstances.  But roughly speaking, such malware can do no more (and actually considerably less) than what a malicious browser extension could do in your browser.

For 1Password, the difficulty is in fully authenticating the communication between the 1Password browser extension and 1Password mini; however, this problem is not unique to 1Password. The difficulty of securing inter-process communication on the operating system is a problem system-wide. A recent paper, “Unauthorized Cross-App Resource Access on MAC OS X and iOS” (PDF),  by Luyi Xing (Li) and his colleagues shows just how difficult securing such communication can be. Since November 2014, we’ve been engaged in discussion with Li about what, if anything, we can do about such attacks. He and his team have been excellent at providing us with details and information upfront.

As always, we are limited in what we can do in the face of malware running on the local machine. It may be useful to quote at length the introduction of that article

I have said it before, and I’ll say it again: 1Password […] cannot provide complete protection against a compromised operating system. There is a saying […] “Once an attacker has broken into your computer […], it is no longer your computer.” So in principle, there is nothing that 1Password can do to protect you if your computer is compromised.

In practice, however, there are steps we can and do take which dramatically reduce the chances that some malware running on your computer [could obtain your 1Password data].

That was written more specifically about  keystroke loggers, and there are some things that set the new attack apart. Like superficial keystroke loggers it doesn’t require “admin” or “root” access, but they were able to sneak a proof of concept past Apple reviewers.

The threat

The threat is that a malicious Mac app can pretend to be 1Password mini as far as the 1Password browser extension is concerned if it gets the timing right. In these cases, the malicious app can collect Login details sent from the 1Password browser extension to the fake 1Password mini. The researchers have demonstrated that it is possible to install a malicious app that might be able to put itself in a position to capture passwords sent from the browser to 1Password.

Note that their attack does not gain full access to your 1Password data but only to those passwords being sent from the browser to 1Password mini. In this sense, it is getting the same sort of information that a malicious browser extension might get if you weren’t using 1Password.

Background

1Password provides its own security. What I mean by this is that for the bulk of what we do, we don’t generally rely upon security mechanisms like sandboxing or iOS Keychain. So it doesn’t matter whether those sorts of security measures provided by the operating system fail.

The careful reader will note, however, that I used phrases like “for the bulk of what we do” and “don’t generally rely upon” in the previous paragraph. There are some features and aspects for which some of 1Password’s security makes use of those mechanisms, and so vulnerabilities in those mechanisms can allow for harm to us and our customers.

1Password mini listens to the extension

Application sandboxing is a good thing for security. But it limits how the 1Password browser extension can actually exchange data with 1Password itself. Indeed, the extension (correctly) has no direct access to your data. Keeping your data out of the browser (a relatively hostile environment) is one of our security design choices. But this does mean that the 1Password browser extension needs to find a way to talk to something that does actually manage your data. 1Password mini (originally the 1Password Helper) was invented for this purpose.

One of the few ways that a browser extension can communicate locally is through a websocket. Browser extensions are free to talk to the Internet as a whole, but we certainly don’t want our browser extension doing that; we only want it talking to 1Password locally. So we restrict the browser extension to only talking to 1Password mini via a local websocket.

Mutual authentication

Obviously we would want 1Password mini and the browser extension to only talk to bona fide versions of each other, so this becomes a problem of mutual authentication. There should be some way for 1Password mini to prove to the extension that it is the real one, and there should be a way for the browser extension to prove to 1Password mini that it is a real 1Password browser extension.

The difficulty that we face is that we have no completely reliable mechanism for that mutual authentication. Instead, we employ a number of separate mechanisms of authentication, but each has its own limitations. We have no way to guarantee that when the browser extension reaches out to 1Password mini it is really talking to the genuine one.

There are a number of checks that we can (and do) perform to see if everyone is talking to who they think they are talking to, but those checks are not perfect. As a result, malware running on your Mac under your username can sometimes defeat those checks. In this case, it can pretend to be 1Password mini when talking to the browser extension and thus capture any information sent from the 1Password browser extension that is intended for the mini.

What can be done

Neither we nor Luyi Xing and his team have been able to figure out a completely reliable way to solve this problem. We thank them for their help and suggestions during these discussions. But, although there is no perfect solution, there are things that can be done to make such attacks more difficult.

What you can do

1. Check “Always Keep 1Password Mini Running” in Preferences > General

In the specific attack that Luyi Xing demonstrates, the malicious malware needs to be launched before the genuine 1Password mini is launched. By setting 1Password mini to always run, you reduce the opportunity for that particular attack.

keep mini running

 

 

2. Keep using the 1Password browser extension

Although what is described is an attack against the communication between 1Password mini and the browser extension through specialized malware, using the 1Password browser extension protects you from a more typical malware attack of pasteboard/clipboard sniffers. Likewise, the 1Password extension helps fend off phishing attacks because it will refuse to fill into pages that don’t match the domain for your saved Logins.

Quite simply, the 1Password extension not only makes life easier for you, but it is an important safety feature on its own.

3. Pay attention to what you install

As always be careful about what software you run and install on your system. On your Mac, open System Preferences > Security & Privacy > General. You’ll see an Allow apps downloaded from: setting there. We strongly recommend confirming that this setting is configured so that only apps from trusted sources can be opened. You can read more about the setting and its options on Apple’s support site.

Now Xing and his team point out that this isn’t a guaranteed way to prevent malware being installed. They were able to get a malicious app approved by the Mac App Store review process. However, I think it is reasonable to assume that now that Apple reviewers know what to look for, it will be much harder for that specific kind of malware to get through.

What we can do

There are additional (defeasible) mechanisms that we can add to our attempts at mutual authentication between the extension and 1Password mini. I will briefly mention a few that we’ve considered over the years.

Encryption with an obfuscated key

One option is to have a shared obfuscated key in both 1Password mini and the extension. (Remember that the browser extension never sees your Master Password so any secret it stores for authentication cannot be protected by your Master Password.)

Obfuscation only makes things harder for attackers until someone breaks the obfuscation, and every system designer should assume that obfuscation will be broken. See our discussion of Kerckhoffs’ Principle in our article, “You have secrets; we don’t,” for some background on why we tend to be reluctant to use obfuscation. Of course, it may be warranted in the absence of a more effective alternative, so this remains under consideration.

In anticipation of a likely suggestion, I should point out that even the magic of public key encryption wouldn’t save us from having to rely on obfuscation here; but I will save that discussion for our forums.

Using the OS X keychain

Another option would be to store authentication secrets in the OS X keychain, so that both our browser extension and 1Password mini would have access to it. This could be made to work for authenticating 1Password mini to the extension for those browsers that allow easy use of the OS X keychain.

This might solve half the problem for some browsers, but to date we’ve been focusing on solutions that work across all of the browsers we support.

An extreme solution

In the extreme case, we could have some explicit pairing (sort of like Bluetooth) between 1Password mini and the extension.  That is, the browser extension may display some number that you have to type into 1Password mini (or the other way around).  With this user intervention we can provide solid mutual authentication, but that user action would need to be done every time either the browser or 1Password mini is launched.

Quite frankly, there is no really good solution for this. To date, our approach has been to put in those authentication checks that we have and keep an eye out for any hints of malware that exploits the known limitations of what we do.

Is 1Password for iOS affected?

The research paper isn’t limited to discussing inter-process communication (IPC) that is done through websockets, but covers a wide range of mechanisms used on Apple systems. This includes some mechanisms that we may use for some features in 1Password for iOS.

Shared data security

1Password for iOS shares some of its data with the 1Password app extension. As most of that data is encrypted with your Master Password, it is not a substantial problem if that data becomes available to attackers. The exception, of course, is the TouchID secret.

As yet, we have not had a chance to test whether there is any exposure there, but watch this space for updates.

Conclusion

We truly are grateful for the active security community, including Luyi Xing and his team, who take the time to test existing security measures and challenge us to do better. Our analysis of the researchers’ findings will continue and we will post an update if further action is necessary.

69 replies
« Older Comments
  1. Marco
    Marco says:

    If I may ask, is there any difference in behaviour between the App store 1Password for the Mac and the one donwloaded from your website?

    Reply
  2. donmontalvo
    donmontalvo says:

    If anything, this thread makes me love 1Password more than ever.

    With that said, now is a good time to ensure dual-factor authentication is enabled wherever possible. ;)

    Don

    Reply
  3. Bryan
    Bryan says:

    I not a programmer so I can’t give any suggestions. Sorry about that. I’m a normal user, but I have a question;

    If I understand right, the exploit works when the browser extension sent information to mini malicious app. Right? So, the malicious app just get what you send from the browser extension to it.

    So my question is…
    The malicious app just can stole “new passwords” that you create? If I one use the browser extension to fill already created password, mini to browser information, is there a problem with that? Is the password vulnerable anyway?

    Reply
  4. eak
    eak says:

    What if the first use of the socket to the back-end had to prove that it possessed the passphrase to the primary vault? For example, the back-end could send a 128-bit random number and the browser extension would encrypt this with the passphrase hash and send it back. This means that the user would have to potentially enter the passphrase one additional time per browser start.

    Reply
  5. eak
    eak says:

    What about requiring the browser extension to prove its identity to the back-end with the primary vault passphrase upon connection to the socket? This would cause the UI to occasionally ask for the passphrase when it would not otherwise be necessary, but this would be at most once per browser start. It doesn’t guard against a MITM attack, of course, but the uniqueness of the socket interface makes such a MITM attack hard.

    Reply
  6. jonathan morin
    jonathan morin says:

    Wow. I’m a huge fan of 1Password and i’m talking about it every time that i can to help people to be more secure with their password. Just a several minute ago i have found the article that is talking about the apple security breach and of course the vulnerability of 1Password.

    I say to my self, lets go to 1Password.com see if they are avoiding the subject or if they are talking about it.

    First article on the forum and I’m so proud that you are talking about it and you’re not trying to hide some where. Now i have a clear understanding of the risk. And also thank to some others peoples around like Temptin that are stepping in and are bringing idea to help on this matters.

    I’m sorry that i can’t bring anything to it. I’m more good with physical security matters though.

    Reply
  7. Erwin
    Erwin says:

    What is the problem with the following design to authenticate 1Password extension with 1Password mini (I’m sure you’ve considered this so I’m just curious):

    1) On first install of the browser extension
    1.1) Authenticate the two pieces of software with the help of the user (like bluetooth pairing)
    1.2) Generate two pairs of private/secret keys (one for each software) and exchange the public keys.

    2) Authentication (a zero-knowledge challenge-response*):
    2.1) Authenticate the extension to the mini: The mini issues a challenge given to the extension encrypted using its public key. The extension decrypts and answers the challenge in encrypted form with the mini’s public key.
    2.2) Authenticate the mini to the extension in a similar way.

    The challenge could be based on a very long-period pseudo random number generator seeded with random input generated during step 1). Of course the PRNG has to be cryptographically strong (no arbitrary “reasonable” sequence of values gives enough information about the seed). This is much like the RSA tokens and such except that the challenge value is randomly chosen (in the RSA token it is the current time).

    Again, I’m just curious where the fault and security weakness lies… (as I see it lies in step 1 above but here we have the help and guidance of the user).

    Kind regards,

    Erwin

    Reply
  8. Oli
    Oli says:

    I must say that I like the way Crypho uses 2-factor identification by sending a code to my smartphone. It doesn’t bother me to enter a code each time I want to use Crypho (once a day).

    Pairing seems interesting. If 1P mini used a launch daemon to initiate the pairing, would malware still be able to take precedence?

    Reply
  9. Oli
    Oli says:

    The way I see things, is that a 1P launch daemon would act sort of as a patrol authenticating both 1P mini and 1P bowser extension using some hash algorithm each time they want to communicate to one another.

    Reply
  10. Stefano (@amazedinchicago)
    Stefano (@amazedinchicago) says:

    Just a remark: I know of one major financial company that modified it’s website so that unless a password in manually entered, login fails. That makes 1Password fail, too. I think its a nudge toward 2-factor authentication.

    Reply
« Older Comments

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *