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
« Older Comments
  1. DJ
    DJ says:

    Hey Jeffrey,

    You mentioned that you “throw away” the keys when the vault locks, and in another comment you mention that you release the memory. Is there any work done to essentially fuzz or memzero the memory before you release it such that the key isn’t just lingering in memory until it’s fully reclaimed/used again?

    Thanks

    Reply
    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      That is a very good question (and I’m sorry for being so late to answer it).

      The answer is “no”. In order to do that we would have to effectively write our own memory manager instead of using what is offered by the compiler and system SDK. There are enormous memory safety features that come with using what the system offers and there are serious and numerous opportunities for error in rolling ones own memory manager. So we have chosen to accept the risk of secrets hanging around in memory a bit longer than we’d like for the safety of using the high-level tools that the SDK and compiler offer us.

      I hope that helps.

    • John B
      John B says:

      Jeffrey,

      Are you sure about your reply? DJ’s suggestion (aka question) seems quite valid. My coding level is quite basic, but if you are storing a value in a variable would you not be able to subsequently write ‘00000000000000’ or similar into that same variable before exiting? This wouldn’t require writing your own memory manager. Yes the OS memory manager could be holding that in memory for an arbitrary amount of time, but it is non longer exposing any relevant info.

    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      I understand your skepticism, John. And I shared your views when I first looked into this after joining AgileBits (then Agile Web Solutions). But it is a brave new world we live in that has such compilers in it.

      A large number of systems these days are underlyingly “copy on write”, so even when it seems like you are changing the value held by a variable, you are actually just creating a new, modified, copy of the original. So even when it appears that you have a mutable data type, you are really working with an immutable one in terms of what actually lives in system memory.

      I grew up on C where if you could point to something you could change its content, so all of this is strange and new-ish to me. But so much of the memory protection that modern systems give us depend on these underlyingly immutable types.

    • John B
      John B says:

      Jeffrey,

      Reply understood and accepted. Thank you for continuing to be transparent, patient, and professional with us.

      I find myself now pondering how OS vendors (Apple specifically) intend to address this. Will they implement a different variable type or property which enables an application to erase a variable they have declared as needing to be “secure”? Again, not a question for AgileBits. Just rambling…

    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      Hello Luca,

      There have been several security updates to major browsers over the past weeks, and so I’m going to say that it seems very unlikely that those can be actively exploited today. But Spectre mitigations are probably going to keep dribbling out from software vendors over the next six months. And each makes such attacks substantially harder to execute (or requires more specific and limited circumstances for exploitation).

      So I am not worried about the kinds of exploits that were demoed in the early days after this was all reported. But it will take time before the world is completely Specter-Proof.

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