Same as it ever was: There’s no reason to melt down

The Intel CPU flaw, that is being referred to as “meltdown”, is a big deal. It allows for a whole (new) category of malware to do things that it otherwise shouldn’t be able to do. This is not a good thing, and it remains a threat until operating systems are updated to no longer rely on some specific security features of the CPUs.

But just because it is an extraordinary bug doesn’t mean that it requires an extraordinary response from most people. (Operating system designers are not “most people.”) The same practices that you should already be doing are enough.

What you can do is what you may already be doing

Stay updated, be careful where you get your software

Malware that exploits meltdown may be particularly powerful, but it is still just malware. And so the practices that we’ve always recommended are the practices that will protect you now.

  1. Keep your system and software up to date
  2. Be careful about where you get your software.

Regarding point 1, it appears that the latest version of High Sierra already has defenses to guard against meltdown. If you are using macOS be sure that you are up to date. It also appears that Microsoft is in the process of releasing a security update for Windows.

For the second point, I recommend downloading software from app stores, such as the Mac App Store and the Microsoft Store. They can’t guarantee that no malware slips through, but they provide the easiest and most effective filter available.

Whatever you do, don’t respond to “scareware”. Scareware is typically sold through something that pops up fake alerts about your system being infected or compromised. These scary (and fraudulent) alerts then try to entice you into installing and running tools that will “clean” or “repair” your system. Unfortunately those tools do the exact opposite of what they claim to do.

Panicked people make poor security choices. And so this is why I am worried that fear about this issue might lead people to become more susceptible to scareware. Take a deep breath, don’t panic, and be calmly suspicious of scary alerts.

What we can do is what we have already been doing

1Password is designed so that even if an attacker can read every bit of data on our systems they cannot learn your secrets. We simply don’t have the capacity to decrypt your data, and that holds of anyone who compromises our systems. This has been essential to 1Password’s design from the very beginning, and it is why we don’t have to panic either.

Furthermore, it appears that AWS (our hosting provider) has already begun patching the servers. Keeping up with updates is one of the things we hire them to do.
1Password Encryption

Same as it ever was

I don’t want to downplay the extraordinariness of this bug. It is fascinating in many ways, and it does have broad impacts. But unless your job is to design and maintain operating systems, you should just follow normal practices of keeping your system up to date and not installing dodgy software.

There is a great deal of speculation and news coming thick and fast and it may well be that some of the details of what I have said here will need correction. But the core message should remain the same. Keep your systems and software up to date, and don’t install software from untrusted sources.

33 replies
Newer Comments »
    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      This is a very good question. It also reflects some of the benefits of using application stores.

      The details differ by operating system. But they all have code signature mechanisms. Our software is signed by a code signing key that in turn is signed by Apple or Microsoft.

      Our updaters also perform their own extra checks on the downloads. The OSes’ checks only show that the software is from a “trusted developer”. We perform additional checks that the “trusted developer” is us for our updates. Furthermore we use the very strictest TLS settings and requirements for fetching the updates.

      PGP signatures don’t have all of the security properties of code signing keys. Code signatures include a trusted time stamp, so that the signature remains valid even after the key expires. Using plain digital signatures for code signing (like you would have with PGP) requires that you can’t expire or revoke keys as frequently as you would wish to because you would “break” earlier good signatures. Every key expiry would mean that you have to resign all of your old software.

      There was a time when showing a PGP signature for some code was the way to do things. But code signing signatures have long since replaced that.

      Cheers,
      -j

    • Levi
      Levi says:

      @jeffery Perhaps I’m ignorant of the mechanism, but how would an end user, such as myself, validate code signatures of software, like yours, that I download? With GPG sigs I know the procedure. Similarly, how, besides your reassurances, can we know the updater process has not been compromised or MITM’d?

    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      If you are using the web store (not Mac App Store) version of 1Password on macOS, you can use

      codesign -vvv -R="identifier com.agilebits.onepassword4 and anchor trusted" /Applications/1Password\ 6.app

      I confess to not knowing how to do this on Windows.

  1. Khad Young
    Khad Young says:

    Treat those scareware messages like a cold call from someone claiming to be from your bank. “Don’t call me. I’ll call you.”

    You wouldn’t give out information to a stranger who calls you, rather you call the phone number on the back of your credit or debit card to verify that the call was legitimate.

    In the same way, if a message on your computer is legitimate, you can come back to it later and use trusted tools to detect the problem rather than proceeding with something that pops up unexpectedly.

    Reply
    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      In my very quick write-up, I don’t distinguish among the variants. But for the point I am trying to make the distinctions don’t matter. Keeping your software and systems up to date as well as being careful about you install (including browser plug-ins) is what you need to do to protect yourself against all variants.

      Spectre may mean things for some software developers. Roughly speaking, many of us will need to recompile our software once we are on patched development systems. This is going to lead to lots of software updates in the coming weeks, but again your best defense is to not run malware on your machines.

      Cheers,
      -j

    • Dave Teare
      Dave Teare says:

      It’s a great question, Johan! Thank you for asking it as it gives me a excellent excuse to talk more about the innards of 1Password and some of the design choices we made. It’s always a fun time being able to do so! 🙂

      I left a rather long winded reply to Nic below that I hope will answer your question. While I’m talking explicitly about Google Chrome and 1Password X, the design choices we follow are applicable to the 1Password desktop extension as well. As for other browsers, most have embraced the “one tab per process” architecture that Google pioneered all those years ago (hard to believe it was almost 10 years ago now!).

      I hope that helps. Please let me know and we’ll dig deeper if you want us to. 🙂

      ++dave;

  2. Colin Jensen
    Colin Jensen says:

    I’m no expert, so I’m sorry if my following questions are crazy-talk!

    What prevents Javascript running on Safari/Chrome/Firefox from accessing any decrypted part of the 1Password keychain using a Spectre exploit? Does Javascript always run in a different process than the 1Password extension to prevent access? Or does 1Password avoid having unencrypted sensitive data hanging around in process memory?

    Reply
    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      Your question is excellent,

      The article I wrote focuses on Meltdown instead of Spectre, which really is a different sort of beast. And the precise implications of it are not fully clear yet.

      But your question about secrets in memory apply to both. Although 1Password may try to reduce the number of secrets it holds in memory when unlocked, that isn’t something to rely on. Even though only a small portion of your data may be decrypted in memory at any one time when unlocked, it is not a fact you should base security decisions on.

      The master keys (the keys that encrypt the keys that encrypt your data) will be in memory as soon as 1Password is unlocked and will stay in memory until 1Password is locked again. While it might take an attacker a little more work to find those keys write exploits that know how to use them, you should still consider this as equivalent to everything being available when 1Password is unlocked.

      As I mentioned in another answer, 1Password throws away these keys when you lock it, but it can’t guarantee that they and other secrets (particularly strings) are instantly purged from computer memory when it does so.

      It’s hard to keep secrets against a mind reader. And any malware that can inspect whatever parts of system memory it wishes to can be thought of as a mind reader of your system. So that is why the focus must be on not letting a mind reader get into your head.

    • Dave Teare
      Dave Teare says:

      It’s great advice as ad networks are a very effective tool for distributing an attack against many would be victims. Preventing the ads from loading altogether nips the problem in the bud.

      Now of course the issue becomes which ad blocker should one use? Some trusted blockers have been somewhat less so over the years. I like 1Blocker myself but it has limited browser support on macOS, which is a darn shame.

      ++dave;

  3. Nic Pottier
    Nic Pottier says:

    Although I appreciate that 1Password’s storage of passwords on servers is safe due to the design of 1Password, this seems to ignore repercussions of these attacks on “1Password X”. Isn’t it vulnerable to these attacks from Javascript running on a website? No malware or out of date software needed.

    From what I can tell Chrome isn’t shipping mitigations for that attack until end of January. Any comments from 1Password on the possible attack vectors there? Should we move away from using “1Password X” until the browsers catch up?

    Reply
    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      That is a really good question, Nic.

      I know that Chrome has long had defenses against a broad category of related attacks, and so I suspect that 1Password X remains safe in Chrome, but there is still a lot of investigation and noise to sift through. I should also note that 1Password X’s design keeps information separated. We have always considered the browser a hostile environment and have designed with that in mind. But beyond those general statements, I don’t have a specific answer for you at this time.

    • Dave Teare
      Dave Teare says:

      Hi Nic,

      Thank you for the excellent question. I apologize for not replying sooner but I needed to take some time to research Spectre. Despite the bombastic headlines I was pretty sure the process architecture used by Google Chrome and the design choices we made in 1Password X were sufficient to guard against it but want to learn more before answering.

      From the Spectre Attacks: Exploiting Speculative Execution paper we know that Spectre is limited to sniffing out information from the process the nefarious JavaScript is executing in:

      As a proof-of-concept, JavaScript code was written that, when run in the Google Chrome browser, allows JavaScript to read private memory from the process in which it runs

      So as far as I can tell the Spectre attack is limited to the process itself. So the question becomes how does Chrome design it’s processes? From the Chromium Process Models design document we learn that:

      By default, Chromium creates a renderer process for each instance of a site the user visits. This ensures that pages from different sites are rendered independently, and that separate visits to the same site are also isolated from each other. Thus, failures (e.g., renderer crashes) or heavy resource usage in one instance of a site will not affect the rest of the browser. This model is based on both the origin of the content and relationships between tabs that might script each other. As a result, two tabs may display pages that are rendered in the same process, while navigating to a cross-site page in a given tab may switch the tab’s rendering process.

      This is specifically about Chromium but I believe Google Chrome ships with the same defaults. So at a very high level, each tab has it’s own process in Chrome (my high-level understanding about the exceptions to this rule are sites that use the same top level domain and sites that contain frames; neither of which are relevant to our use case) and so a compromised tab would not be able to read any information from any other tab.

      This severely limits Spectre’s potential for mischief as a nefarious tab would “only” be able to steal information from other frames loaded in the same tab and other tabs with the same top level domain.

      While this is a bad thing in general, for 1Password specifically, the exposure is very little as we designed things such that your sensitive information doesn’t live in the same process as the running web pages (and 1Password.com doesn’t use iframes nor does it serve any ads or JavaScript from other sources).

      We designed 1Password X so that your secrets are kept in what is called the background page, which runs in a process of it’s own. You can visualize this in Activity Monitor on macOS:

      The highlighted row in the image is the background page of the 1Password X extension, and you can see from the Process ID column that it has it’s running within it’s own unique process.

      In sum Spectre is an absolutely spectacular demonstration of how amazing security researchers are at finding exploits, and while it really is a serious issue for websites that serve ads and run JavaScript from untrusted sources, for 1Password it is not something that keeps us up at night. Okay, okay, it was something that caused us some lost sleep as the headlines in the media are indeed quite scary, but once we dug deeper, we found our security design and design choices provided excellent protection.

      I hope that helps explain things. Thank you again for the excellent question and giving me the pleasure of answering it. 🙂

      Take care,

      ++dave;

  4. Ed S
    Ed S says:

    You say: “…even if an attacker can read every bit of data on our systems they cannot learn your secrets.” If an attacker can access “system memory” – or whatever extra “powers” the new vulnerabilities enable – you’re saying he still cannot access the passwords in 1Password? I get it the encrypted 1Password database is safe; however, aren’t passwords not “at rest” at risk? I’m concerned that when I access and use passwords in 1Password (e.g., via auto-fill in browser or copy to clipboard) the confidential data is exposed to these vulnerabilities. I use the desktop version of 1Password. Thank you –

    Reply
    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      Hi Ed,

      As you can tell, the article was written in a hurry, and it appears that I failed to express things very clearly.

      In that particular passage you quote I was describing the behavior of our systems. Elsewhere I describe how things behave on your systems. On our systems we never have your secrets, but on your systems you do. So you are right that your own systems are at risk from malware that can read the memory of your system.

      And that is why I have taken the opportunity to remind you of practices to help keep your systems free of malware.

  5. John B
    John B says:

    Jeffrey,

    I am a lo—–ng time user and would like to start by thanking you for your software quality, transparency, and attention to security.

    I understand 1Password had always been a standout in terms of protecting our data and particularly our data at rest. The thing that concerns me are Meltdown and Spectre exploits running on my devices in a particular vulnerability window that I see. For this conversation let’s stick with MacOS.

    In my current setup I have the application, the menu bar helper, and browser extensions all in use. If a malicious app successfully reads OS memory occupied by 1Password data what will it see in these two scenarios?
    1) 1Password locked
    2) 1Password unlocked

    I am hopeful that with a transparent reply from you I can come up with a safe mitigation strategy until hardware, OS, and/or browser fixes are in place from Apple.

    Thanks,
    John

    Reply
    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      That is an excellent (and tricky) question, John.

      1Password throws away its encryption keys on Mac and Windows when it locks, and it instructs the operating system to release memory. So that is the good news. The bad news is that 1Password can’t force the operating system to “forget” things when we want it to. So some secrets may hang out in operating system memory even after 1Password is locked.

      (OK, technically we could, but it would require using our own memory management structures instead of using what is offered by the compilers and operating systems. But we feel that the dangers of writing our own low-level memory manager far outweigh the benefits of being able to overwrite secrets instantly in memory.)

      So 1Password throws away secrets when you lock it, but it may take an unknown amount of time before any particular secret is eradicated from the computer’s memory.

      I know that that is a messy answer, but these things are inherently messy. I hope it helps anyway.

    • John B
      John B says:

      Jeffrey,

      After reading your replies to my post and others I think I have a better understanding. I also now realize there are probably three states that need to be considered.

      For this discussion let’s ignore the specific bug and exploit, and just consider a malicious process being granted access to 1Password’s memory due to a hardware, OS, and/or browser bug.

      These are the three states I have inferred:
      1. OS freshly rebooted. 1Password never unlocked.
      ==> There is nothing in memory unencrypted. Nothing is vulnerable.

      1Password currently unlocked
      ==> Two buckets of data directly vulnerable in memory throughout the period the app and vault remain unlocked: a) the master encryption key, and b) any specific data that the user has accessed.
      1Password was open, but has subsequently been locked by user action or timer
      ==> The answer is actually the same as #2 above, but there is a random chance that the OS will purge the information from memory. Due to MacOS memory management design there is no conventional way for 1Password to force purge the information, It is up to the OS and invisible to 1Password and users.

      Please do take the time to explicitly confirm and/or comment on the above item by item.

      The master key being exposed is quite a concern for me. I should have been able to realize this, but had overlooked it. Wow. This is bad.

      To others reading, I in no way blame 1Password or Agile Bits for this. This is a fundamental hardware and OS bug.

      Regards,
      John

    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      Hi John,

      You are fully correct for states (1) and (2). For state (3) I would say that “most secrets are probably gone from memory, but we can’t guarantee it”. There is a substantial difference between states 2 and 3, that is not reflected in your characterization.

      And yes, this is bad. But again, it is not really worse (for you) than any other memory-reading malware running on your OS (always a bad thing). I don’t know if it is reassuring or frightening for me to point out that memory reading malware is not a new thing. And this is why I warn about scare-ware. I am honestly more worried about people getting tricked into installing more traditional malware than becoming victims of attacks that exploit Meltdown and Spectre.

  6. Barry Levine
    Barry Levine says:

    What (if anything) does 1Password do in order for it -not- to be vulnerable to “Meltdown” and “Spectre”. Let’s assume my Mac or PC somehow gets infected with whatever malware takes advantage of those “flaws”; will my login info (when I ask for 1Password to provide it) be safe or will the flaws permit that malware to read the data I’ve just asked 1Password to retrieve and paste into the appropriate fields?

    Reply
    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      Hi Barry,

      If your machine is infected with something that exploits Meltdown, then there is nothing that 1Password (or any other software running on your machine) can do to protect its secrets. This is why, in terms of Meltdown, it is on you to keep your system free of malware. Note that this isn’t specific to Meltdown. Any malware running on your machine that is capable of reading “protected” memory would be in the same position. There is an old saying, “once your computer is compromised it is no longer your computer.” Meltdown isn’t about vulnerable software applications, it is about vulnerable operating systems (through quirks of the CPU). The latest version of macOS (10.13.2) is safe, and Microsoft just released a Windows update on January 3.

      Spectre is a bit different. And I am hesitant to say much because frankly my understanding of it and mitigations is, as they say, “still evolving”. Software that has been compiled in a particular way may be vulnerable. We are waiting for Apple and Microsoft to tell us whether we need to re-compile 1Password and if so to provide us with the tools to do so in a Specter-proof way. Again, this is my understanding at the moment. Note that it is much harder to exploit Spectre than Meltdown.

      Also some browsers have modified their behavior to make it harder (or impossible) to launch some of the attacks from malicious web pages. But I haven’t been able to keep track of exactly what browsers defend against which attacks. Again, keep your systems up to date.

Newer 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 *