Article just published in Washington Post is saying 1password and others have security flaws

Comments

Correct me if I'm wrong, but despite this weakness, this would prevent the scenario that many have brought up where there is a BSOD and the entire contents of everything 1Password has stored in RAM gets saved in plaintext in a crashdump - which could then be sent to a 3rd party as part of a telemetry package.

If I can be allowed to temporarily ignore the last part about the third party telemetry package, then yes it could've help in that very specific situation where a computer had a system failure and then someone have stolen your computer with that information. That's the problem, you still need the complete dumps to be stolen and everything that's in memory is exposed. Could your 1Password data be minimized with that API, probably but then again, you have to have a series of events; you had a complete system failure while 1Password was unlocked already (regardless of lock later) and you have a third party tool uploading the large memory dumps to their services, which is also a bigger problem.

We have a massive problem if these memory dumps are allowed to leave your computer without your permissions or knowledge.

If by telemetry package, you're referring to Windows Error Reporting (WER), then 1Password is already coded to opt out of the Windows Error Reporting (WER), which means its crashes are never dumped nor sent to anyone. However, that also relies on Windows and Microsoft to do the right thing here but we can test this with system and network analysis tools. You can also configure Windows to not generate any dumps in the event of system failures. If you'd like to know how, let me know and I'll explain.

Let's be clear about this; no one should be including complete memory dumps in any form of telemetry package without the very clear and explicit permissions from you. That is a compromised system right away, if a third party is doing this, that's a malware you have to remove from your system at all costs. Even if you're not using 1Password, any other tool would be affected. Yes, 1Password would be worse off because storing more data in memory and yes, minimizing the data usage in memory could protect against this very rare situation.

I'm not advocating this as a solution, but theoretically if I were to disable Watchtower within the 1Password client, would that limit the amount of data that gets loaded into RAM to those passwords which I access directly?

In theory, we can opt out of everything; minimize everything and you'd have an app that's probably going to be like the original 1Password app; no extension, no Watchtower, no security benefits to help. You're only allowed to see one item at a time; searching would take forever.

This is where the conversation about the security tradeoffs come in.

Wouldn't this allow you to force Garbage Collection so that unneeded data was cleared out of RAM?

We've tried it and it works best when you terminate the process entirely; as long as 1Password keeps running, we see a reduction in memory usage but the strings are still in memory for awhile.

Keep in mind what that Docs already mentioned a few times like these:

All objects, regardless of how long they have been in memory, are considered for collection; however, objects that are referenced in managed code are not collected.
However, using this method does not guarantee that all inaccessible memory in the specified generation is reclaimed.

and more.

Moving away from .NET and garage collector is by switching to Rust is one approach we're working on that may help.

You've opted for convenience over security. We all do at times. That's an acceptable choice, but doesn't eliminate responsibility for the consequences of that choice.

Certainly not. And we have taken steps to resolve this issue in our organisation. And I even opened an issue for homebrew for them to fix theirs. I don't want to shift blame here - there certainly are risks involved in this method. But I do think that Agilebits working with the community is important, too. At least from where I stand, I can see this being an issue for others as well, and thus Agilebits would be well situated to help those people. From my point of view, I don't really have a problem. As a last resort, we will simply stop using 1Password due to not having our needs met. Inconvenient, but totally doable.

Unfortunately I later verified that this is incorrect, reposting here:

Tried with UAC at highest level, same thing: on win10, admin account (I expect majority of users running that), UAC at max, 1password unlocked and relocked, I can launch HxD (a hex editor that can read process memory as well) without elevation prompt (I see it running in the same context, elevation level and other security related bits in process explorer) and open 1password memory and search for my passwords as UTF16 strings.

That means a browser or anything else running on the system can as well. Browser is most worrying because that is the main way remote code can be executed en-mass if browser itself has an exploit.

Workaround for current version is to launch 1password itself with elevation.

@tesmi: I did not imply that. Modifying the binary would invalidate the signature. I guess I just don't understand why you're seemingly going out of your way to circumvent security.

Please clarify the specific issue you're facing, and/or the specific threat that you're concerned about. From your earlier comments, it sounded like a thought experiment. But if you have steps to reproduce a bug or security issue that needs to be addressed, I'll be happy to look into it for you.

I thought I had already. But I can use some time to illustrate my issue further. This is not a theoretical issue, this is something that already happened. I'll take some time to get a walkthrough of the exploit in a VM. The bottom line being: A signed, trusted, 1Password binary is running on a patched macOS Mojave computer with SIP enabled, but the user can, without installing any additional tooling or root access, dump the master password on the screen with one short shell command.

Ah, thank you @UnFleshedOne for the correction. There are questions that I should leave for our Windows team. I come from a Unix world and so I perceive an Administrator account as having "elevated privileges". While technically correct, in practice you are almost certainly correct that in the way that people actually use Windows, I shouldn't think of it that way.

Where would I find directions for preventing Windows from creating dumps?

You can find it by opening Windows File Explorer, right-click on Computer on Windows 7 or This PC on Windows 10, to select Properties.

Now, click on Advanced system settings on left sidebar and then go to Advanced tab to click Settings under Startup and Recovery. You can then adjust the settings for System failure, turn off the debugging information or use the more narrow dumps.

It was mentioned somewhere that despite 1password opting out of WER the dumps were still occurring.

I believe that was a system failure with a complete memory dump but it all depends on what the system configuration was set to and what they were doing to test, the original case study author had a hardware failure and they were able to see the entire memory content of everything.

@tesmi:A signed, trusted, 1Password binary is running on a computer with SIP enabled, but the user can, without installing any additional tooling, dump the master password on the screen with one short shell command.

wait, are you serious? this is crippling and i almost don't want to find out if it's true.

still highly worrying to know that 1Password loads so much plaintext into memory that can be dumped though. this is a critical error, and shoving responsibility to the end-point is not appropriate - especially when considering the techniques needed to bring better security are so basic (yet still not implemented).

Browser data is not encrypted, by default. It's stored to disk not encrypted, or encrypted only by a process that any app running under your user account can easily decrypt. There are plenty of malware apps out there for scraping saved credentials from browser profiles, for all the major browsers. Some browsers offer a "master password" feature to encrypt the local data, but it's not mandatory, you need to set it up separately on every device, and in some browsers it interferes with other browser features (or it did, previously).

It is encrypted on the server (I do not know about any browser, but on Firefox and Chrome), maybe this is not the default option, but it anyway could be encrypted. So no issues on the server data leak.

Yes, it is probably stored on endpoint computer unencrypted, but what the difference with 1Password now? Before the cold boot everything is encrypted by system BitLocker or Filevault, I do not care about the 1Password encryption before the system boot. And now, after I unlock my 1Password vault game over: everything is stored in the memory unencrypted. There is no difference for me now. I was 100% sure that 1Password lock removes everything from the memory.

You'd also be missing out on easy

I will definitely miss some features, especially the family share. On the other hand 1Password fill is a little buggy, especially on browser update. Firefox, for ex., done a lot of in the area of Watchtower, mobile companion app, etc.

So next year, I will compare only features, not the security. Security is currently the same for me, unfortunately. Will I be ready to pay 60 USD for the family share and some other features, I do not know, probably not.

Certainly not. And we have taken steps to resolve this issue in our organisation. And I even opened an issue for homebrew for them to fix theirs. I don't want to shift blame here - there certainly are risks involved in this method. But I do think that Agilebits working with the community is important, too. At least from where I stand, I can see this being an issue for others as well, and thus Agilebits would be well situated to help those people. From my point of view, I don't really have a problem. As a last resort, we will simply stop using 1Password due to not having our needs met. Inconvenient, but totally doable.

@tesmi: Apple has gone to a lot of trouble to put these security measures in place, and has also been very clear to 3rd party developers about how we fit into the security model. That's why we moved to a signed installer package a few years ago. We're not going to go against the platform owner when they're right to set this standard to protect end users from exactly the issue you seem to be concerned about. You don't need help from us, or from Apple, here; you need to stop hurting yourself, and take advantage of the security measures in place, by default, in modern versions of macOS. I'm sorry if that seems harsh, or like I don't care; but if I didn't, I wouldn't be pleading with you to do the right thing here, instead of doing the wrong thing and expecting someone else to somehow right it for you.

This really seems like a completely separate discussion from this thread about memory management in Windows password managers though.

but we are also considering the possibility of terminating the process at lock (then how do you protect the secrets as it passes from one process to another process?), this has unexpected side effects.

Why do you need to pass through any secrets from old instance of 1Password to new instance? User still has to enter master password when unlocking, there is no UX impact of starting from scratch (aside from PIN unlocks maybe?).

This really seems like a completely separate discussion from this thread about memory management in Windows password managers though.

It's the same exact problem. Passwords and specifically, the master password, residing in memory after 1Password has been locked. The difference being that 1Password is secure by default for this type of attack in macOS when installed using your installer, but not on Windows, where the SIP-provided memory protection does not apply.

You don't need help from us, or from Apple, here; you need to stop hurting yourself, and take advantage of the security measures in place, by default, in modern versions of macOS. I'm sorry if that seems harsh, or like I don't care; but if I didn't, I wouldn't be pleading with you to do the right thing here, instead of doing the wrong thing and expecting someone else to somehow right it for you.

Could you then please remove the .zip file that homebrew is using to install your application from your servers? To make sure to say this is not a trusted method to deploy your application and thus preventing it. It's bad for your reputation to have this exploitable binary around.

@nikanorov - sometimes our forum software filters will flag a post for moderation, which means it won't appear until one of us approves it manually. I've just done that with your post, so it should appear now (or shortly). Please refresh the page and check for it.

@jpgoldberg , I also come from a UNIX/Linux background. And unless something has changed in recent years (or it's flavour dependent) terminating or restarting the process would not, strictly speaking, solve the problem. When a process exits, the memory allocated by a process is added to the dirty page pool by the kernel. It's not actually cleared until the system starts running low on free memory. At this point, the page scanner will run through the dirty page pool, clear the memory, and add it to the free page pool. The same holds true if you simply free() it. In my understanding, to be secure, the relevant memory would need to be overwritten prior to being freed, or the process exiting. I can only speculate whether the same holds true for Windows.

That said, one would require privileged access to examine memory in the dirty page pool.

My apologies if this has been said previously. This has become an incredibly long thread and I might have missed it.

Why do you need to pass through any secrets from old instance of 1Password to new instance? User still has to enter master password when unlocking, there is no UX impact of starting from scratch (aside from PIN unlocks maybe?).

Yep, that's how Windows Hello and Secure Desktop works. It would be optional by default; the process is to scramble a one-time key that the other instance could use only once.

. And unless something has changed in recent years (or it's flavour dependent) terminating or restarting the process would not, strictly speaking, solve the problem. When a process exits, the memory allocated by a process is added to the dirty page pool by the kernel. It

Exactly, we're not saying it would solve the problem but it will be easier for the system to "scrub" the process memory when its been marked as terminated; we've found that it is faster to do this and more reliable than trying to minimize or reset a running process memory.

There's no 100% sure fix to this but this would help in a long way against the memory dumps and stolen laptops.

Was his threat of suing for false advertising too much for AgileBits? Anyway, to all wading through this huge thread: There is no new threat. AgileBits knew it all along. Threat mitigation is low on the priority list, implementing fancy features like WatchTower is more important.