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 CommentsNewer Comments »
  1. Jim
    Jim says:

    I’ve been fiddling around with this since reading the original paper. It’s possible to use lsof to look at port connections on a system (lsof -i). Would it also be possible to make a determination if there’s a malicious eavesdropper on port 6263 by checking the lsof output periodically to see what’s using that port? It should be just 1Password Mini and your browser, yes?

    Reply
  2. jb510
    jb510 says:

    Nice writeup. I greatly appreciate clear, thorough but concise write ups like this that steer clear of the FUD. Worth noting that you, understandably, are focused here on the websockets / scheme hijacking vulnerability, but that XARA vulnerability means the OS X Keychain is vulnerable directly… so storing keys there would be like storing the chickens in crate with a dog door…

    Hopefully Apple will get keychain / sandboxing fixed promptly, because I feel very naked at the moment.

    It’s easy to say “install apps from trusted sources” but most of us DO have apps installed that auto-update in the background and right now any one of them could auto-update into password thief…

    Reply
  3. Chris Upjohn
    Chris Upjohn says:

    Personally I’d prefer an extreme method where my phone is used in the authentication process. I already use it for a number of 2-step logins so it wouldn’t impede my workflow at all.

    Reply
  4. Arend Abel
    Arend Abel says:

    To what extent, if any, is there a similar vulnerability in the Windows world (where I live). Also, I was not 100% clear on whether this vulnerability affects the iPhone, as well as Mac and IPad. I thought (erroneously perhaps) that the iPhone version of Safari didn’t have an option to use 1Password extensions (which of course means that I’ve been using cut and paste, which I assume carries the vulnerabilities you mention).

    Reply
  5. Nate M
    Nate M says:

    I feel I must be missing something here, else the solution seems rather straightforward. I admit in advance I have no deep knowledge of how 1Password mini or extension operate.

    This particular attack is predicated on the idea that a malicious app gains control of the websocket before 1Password can. If that’s true, wouldn’t that also mean that 1Password is no longer listening on that websocket? Assuming thats the case, and this is not a man-in-the middle style attack (it was not clear in the paper) via the websocket protocol, then why not simply add a second handshake?

    1) Websocket handshake opens channel
    2) Etension requests permission to talk to mini (sends signed ID?)
    3) Mini checks to see if it knows the ID (from the install)?
    4) Mini returns randomly generated session token (used for encryption for a limited period)
    5) Etension does its magic

    If the attacker hijacked the port, the handshake would fail because mini is not there to answer
    If the attack is a man-in-the-middle, then it will witness the handshake, but this is where public key encryption could come in handy to protect the exchange.

    So. Go ahead and tell me. What am I missing?

    Reply
  6. Fernando
    Fernando says:

    Why not establish a secure TLS connection on the websocket using a certificate for authentication? Yes, it would require an Internet connection to validate the certificate but if the browser extension is being used, chances are a connection is available. At worst the user types in the password manually if no connection is available and a small latency is introduced if it is available.

    Reply
    • john welch
      john welch says:

      That’s what I was thinking. Since the browser extension is rarely, if ever going to be used in an offline situation, using an external secure validation mechanism would seem to be a way to deal with this. For cases where having a third party auth isn’t an option, 1P could build (and sell) a component that would tie into internal systems, ala AD that could be used in the same way.

      If there’s a situation where the server-side key might be broached, invalidate it and have people download new versions of the affected components.

  7. Richard Liu (@ulyssesric)
    Richard Liu (@ulyssesric) says:

    Actually that’s two problems, bogus 1P mini, and bogus 1P extension. For the second part I’ve no solution except for encryption; malware could even mimic itself as faked browser, and send faked WebSocket request with correct bundle ID. In fact I’d claim it as an EBKAC and ignore that if it’s up to me. But for the first part, I’ve some idea.

    The problem is that extension will send “raw” web form and password to “some process” that occupied specified port. So the solution is quite simple: DON’T send content value of ‘type=password’ field to 1P mini during a save request.

    When 1P mini get the request, it should fetch web content from given URL within 1P mini process, parse HTML, identify the target form, fill the rest field, and ask user to type password again with a modal dialog. This password is directly input into 1P mini, thus eliminate any possibility of IPC hijacking.

    In other word, when users are trying to save login directly from web with 1P extension, they’ll have to re-enter the password again.

    It’s not a perfect solution but I’d accept that, since no one will create new logins so frequently.

    Reply
  8. edward
    edward says:

    And this is why you should employ two factor on everything important.

    Assuming of course the malicious software can’t get access the the underlying generator identifier

    Reply
    • Edward
      Edward says:

      If someone steals your password but doesn’t have your decaying key you’re really not in so much trouble.

    • Edward
      Edward says:

      Sorry to clarify. If they grab s one time Passover stay code is good for 30 decided if they have access to the underlying code of the authenticate to replicate the token production

    • Edward
      Edward says:

      I’m a huge fan of how one password has implemented authenticator into their software on both the Apple Watch and how convenient it is to access from with in Safari on iOS

« Older CommentsNewer 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 *