Article just published in Washington Post is saying 1password and others have security flaws
Comments
-
If, however, I install 1Password from the packaged installer from the 1Password website, it will have the runtime hardening enabled and attaching a debugger will result in [...] and some other messages in the kernel log.
Can you please explain me how I can check the kernel log? (Do you refer to the output of
dmesgor something else?)Reason for asking: I use a tool that scans for outdated macOS software and can update outdated software with the click of 1 button. While the tool downloads the updates from the website of the the outdated software I don't know what it does for 1Password: use the installer (that apparently has runtime hardening) or the zip file (that does not seem to have it)?
I'm not sure I can test it now, since the last 1Password update was very recent and that was definitely 1Password itself updating.
0 -
Can you please explain me how I can check the kernel log? (Do you refer to the output of dmesg or something else?)
Reason for asking: I use a tool that scans for outdated macOS software and can update outdated software with the click of 1 button. While the tool downloads the updates from the website of the the outdated software I don't know what it does for 1Password: use the installer (that apparently has runtime hardening) or the zip file (that does not seem to have it)?
I'm not sure I can test it now, since the last 1Password update was very recent and that was definitely 1Password itself updating.
For the kernel logs, I was only using
dmesgTo list the entitlements an app has you can run
codesign -d --entitlements - path-to-app.app0 -
@tesmi as @Mrc alluded Apple doesn't support homebrew. 1Password doesn't support homebrew. Commercial solutions like JAMF/Casper can manage mass deployments and stay within the intended sandbox.
If you choose to use non-standard, unsupported software deployment solutions, you have to accept the risks that go with it.
0 -
codesign -d --entitlements - path-to-app.app
Thanks.
Is everything OK when I see
com.apple.security.app-sandboxset totrue?(Or do I need to check something else?)
0 -
May I just clarify one more thought - security best practise dictates security in depth, not complete security as that is a pipe dream. Traditional safes are rated in terms of time to crack - not "perfectly secure" or "uncrackable". Software systems are no different, yet they are not rated this way.
1Password's vault on disk is encrypted to prevent a certain type of attack - offline brute force attacks from a copy of the vault at rest. This is important as the vault is at rest for as long as it exists - meaning the exposure window is practically the same as the duration the machine is online for local or remote attackers, and indefinite for local attackers who can take out the hard drive / steal the machine. So regardless how hard it is to hack in to a machine / walk up to an unlocked machine and copy the vault for offline cracking, the exposure window dictates that this is a significant risk and needs to be protected against.
1Password locks the vault after a certain time of inactivity. This is to prevent a type of attack where (a) an attacker can walk up to an unlocked PC and click through the password entries and write them down, or (b) prevent a remote attacker from installing screen grabbing malware or reading Windows / Mac form control elements from memory if you are not at your desk. If 1Password did not auto lock, and stayed open, the exposure window would have been the same as the duration 1Password is running - which in most people's case would be the same as the uptime of the PC. By auto locking 1Password is trying to reduce the exposure window of this class of attack. Since this is also a significant exposure window, it needs to be protected against.
Now, when 1Password locks the vault, it is safe from prying eyes (someone walking up to the PC), and it is safe from screen grabbing / recording malware. But we now found out it is not safe against malware that reads system memory, even if it is locked. The exposure window is similar, however the difficulty of exploitation is a bit harder. That reduces the risk window - yes, but it does not mean it is not a significant risk that also needs to be addressed. So one option is to force relaunch the application on lock - ugly but possibly beneficial. It is completely accurate that the OS will not immediately clear the process' memory, however at the very least the exposure window has been reduced. The time this memory will be accessible has been reduced as it is marked for reuse. So it is an improvement.
Every improvement in security adds to the layers of defense. I am not saying relaunching the app is the solution, it is just one example, point is that security is not an all or nothing. You do no need to wait until you can implement LML perfectly before implementing some mitigating solutions. Look at what Intel and Microsoft did with Spectre - they released a series of mitigating solutions that build on top of each other as it was impossible to release a single solution that fixed all the issues. At least the issue is being reduced in severity as time goes on; I feel AgileBits should do the same with 1Password.
0 -
I use a standard acc (for daily things) and a separate admin acc (just for UAC prompts), so my 1password memory shouldn't be readable, right? Have you also tested this?
Just tried this on win7 VM, standard account, with UAC at max. No difference, can read 1Password memory from another process running with the same permissions.
If you have one of the security suites (zonealarm, comodo, etc) that monitor processes behavior at reasonably secure settings, they might flag that one process is trying to read memory of another (didn't test it in this case, but I saw related popups from them before).
0 -
Every improvement in security adds to the layers of defense. I am not saying relaunching the app is the solution, it is just one example, point is that security is not an all or nothing. You do no need to wait until you can implement LML perfectly before implementing some mitigating solutions. Look at what Intel and Microsoft did with Spectre - they released a series of mitigating solutions that build on top of each other as it was impossible to release a single solution that fixed all the issues. At least the issue is being reduced in severity as time goes on; I feel AgileBits should do the same with 1Password.
This ^
All too often with software companies they take the attitude that they're just not going to do something because it's not perfect (the best example that comes to mind is when Chrome decided to stop obscuring passwords stored in their password manager because they weren't encrypted).
Anything Agilebits can to do to move the security ball forward incrementally over time is a win. I understand resources are limited but a number of things have been pointed out in this thread that would help move that ball forward. I respect you have larger plans in mind (Rust, LML), but it would benefit everyone if you could pick off some low hanging fruit that works toward mitigation in the meantime (e.g. restarting the app when it's locked to clear RAM).
Also - I think some help from a PR company / department would go a long way at the moment. Some type of official statement that you've posted to your blog etc is really needed. If you leave people to wonder, they often times think the worst...
0 -
I did the research into this in a VM to try to reproduce the issue with homebrew - which I had already seen in other computers before.
Turns out that what had happened was an older version of 1Password had been installed (a version prior to 7.2) and those do not come with Hardened Runtime. Using 7.1.2 I was able to reproduce the behavior - several minutes after locking 1Password it still had the master password in memory, which I was able to dump on the computer.
An upgrade to any newer version of 1Password immediately fixed the issue. I'm still unsure why the 1Password native upgrade mechanism had not worked, as it kicked in almost immediately after I ran 1Password in the VM and worked just fine. So, as a result, things are looking good! An upgraded version of homebrew already installs 7.2.5 and it is fully protected by hardening.
Apologies for being harsh, this is my mistake. I should have been more thorough in my testing before.
0 -
May I just clarify one more thought - security best practise dictates security in depth, not complete security as that is a pipe dream. Traditional safes are rated in terms of time to crack - not "perfectly secure" or "uncrackable". Software systems are no different, yet they are not rated this way.
I read many comments in this thread by AgileBits employees that absolutely don’t seem to understand this. The weakest link will be used to break the chain.
0 -
Anything Agilebits can to do to move the security ball forward incrementally over time is a win. I understand resources are limited but a number of things have been pointed out in this thread that would help move that ball forward. I respect you have larger plans in mind (Rust, LML), but it would benefit everyone if you could pick off some low hanging fruit that works toward mitigation in the meantime (e.g. restarting the app when it's locked to clear RAM).
+1.
For example, I am really can be vector of such attack. It is common in Russia that inspection authorities ask for the access to computer/laptop. They use some software to verify the software licenses or search for the specific information. I am sure they have some advanced software from vendors like ElcomSoft etc. Until now I was sure that my passwords are safe, when locked. Now I understand they could be vulnerable. At least I know this now.
0 -
I am disappointed that 1password has this major security issue, but I am more disappointed at the attitude of employees replying in this thread. Let me summarise the issue and main arguments against addressing it.
Issue: 1Password cannot deliberately clear its memory when it is running after first unlocking, so ANY process on the same machine can read EVERYTHING stored by 1Passwod during the ENTIRE lifecycle of the application. For people that normally put computer to sleep instead of shutting it down, it means the ENTIRE time of the computer session.
Example threat case: A user unlock the 1Password in a clean PC, and during the life of the PC session, he installs an app that has the intention to steal the credentials. It might be a malware, or any legitimate app by someone who is bored and curious (such as some free video converter, a small game, etc.) The app launches, scans the memory and locates 1password, reads everything, sends it to the developer and shutdown this capability forever. Within 200ms of double clicking, without even confirming the UAC, ALL your top secrets are gone without your notice. Because passwords carry so much money value, I bet a lot of hackers or even developers are starting to secretly work on this capability as we speak, because it is SO EASY TO IMPLEMENT AND DEPLOY.
Argument from 1password team: We know this issue from the moment we decided to choose the new programming language and it is a trade off in our view. Keeping system clean is user’s responsibility. 1Password should not run in a compromised system. It is not possible to clear the memory after use in the new language. So we are not going to do anything except doing some preliminary investigation into a new language which we do not promise to use.
Honestly, if I am a manager in a company, I would immediately forbid the use of 1password in the company, let alone adopting 1Password business to my employees. If any of my employee tries to open a game on the company pc, the credentials to access the company system is leaked.
As a security company, I believe you all understand security is IN-DEPTHS. The security of the system is protected by not one method, but a combination of various methods that work together. That is why we have things like admin rights, UAC, antivirus, firewall, full disk encryption, 2FA, etc. That is why there are four umbrellas in your own security design. That is why we have auto lockouts for 1password on every platform. Security is in layers. That’s the basis of all our discussions.
But here is the case. No matter how strong your master password is, and no matter how many layers of protection 1password currently has. All user has to do is to run a single app developed by someone who has the slightest intention to monetise personal data. Because we don’t personally know every developer of every app in the world, does that mean we can’t install ANY app if we are using 1Password?
Indeed, you may not be able to clean the memory in the current programming language, but as others have clearly suggested, there are certain ways to workaround this to achieve the similar effects. Measures such as restarting the app after locking or auto locking, and decrypting sensitive fields only while interacting are good starting points, as they significantly reduce the attack vector and are not that difficult to implement in the current framework.
In addition, I think this incident should ring alarms in your team on how security should be the number one priority and goal in the entire lifecycle of your software development, from choosing the frameworks and languages, to actual implementation on different platforms (decrypting everything upon unlocking is not a good implementation in security perspective). Your product is not just another app, it manages every digital secret of your user, and sometimes, it determines your users life and death.
I really hope 1Password take it more serious and start facing and addressing this issue immediately. Do not burry your heads in the sand and say we can’t do it and we don’t need to. Because you can, and you have to. There is no excuse.
0 -
Apologies for being harsh, this is my mistake. I should have been more thorough in my testing before.
No worries. Seriously. :)
I actually think all of this energy around this thread is a good thing -- it means people are passionate about security for certain, but also about 1Password -- just like we are. My only caution is against anyone making the assumption that what we do (or don't do) results from bad faith, laziness, incompetence or greed. We may not always agree with user suggestions even after they've been fully explained - heck, we don't even always agree internally! - but we'll always listen, and be willing to share our own thought processes and decisions. There's no question we don't have all the good ideas 100% of the time, and that's why spirited discussions like this one with users who are kind enough to take the time to share their own experience and ideas with us are often so productive. The benefit of these discussions tends to decrease in direct proportion to the degree a collegial and forgiving exchange of ideas is supplanted by assumptions of bad faith, badgering, invective or veiled threats of legal action. So deep thanks for being part of the former and pushing this conversation forward instead of sideways. :)
0 -
@UnFleshedOne Thanks for checking. Not good. I use Sandboxie for some programs, but Mem read is still there possible it seems. I use a security suite too, but I'm not sure if it would alarm me. It may be time for HitmanPro.Alert again.
@tesmi They hold back updates from 7.1.2 back due to the necessity of Safari 12 for 7.2x (this is at least the answer I got: https://discussions.agilebits.com/discussion/comment/482959/#Comment_482959)
0 -
They hold back updates from 7.1.2 back due to the necessity of Safari 12 for 7.2x
That's right. We're currently monitoring the adoption rate of Safari 12 to see when it's widespread enough that we'll interrupt/break fewer users' workflows by allowing updates past 7.1.2 on pre-Mojave Macs. Right now, if we allowed that, there would be an avalanche of users whose ability to use their chosen browser would simply break overnight.
0 -
In addition, I think this incident should ring alarms in your team on how security should be the number one priority and goal in the entire lifecycle of your software development, from choosing the frameworks and languages, to actual implementation on different platforms (decrypting everything upon unlocking is not a good implementation in security perspective). Your product is not just another app, it manages every digital secret of your user, and sometimes, it determines your users life and death.
When Safari was being developed, Jobs told the original team it had to be fast. That was far and away the number one priority.
The team's manager, Don Melton, came up with a rule that no matter what changes occurred to the code, it couldn't make Safari slower. His idea was if they do nothing to make it slower, but only do things to make it faster, slowly they'll hit Job's goal (and they did).
Agilebits needs to look at security this way. Nothing should ever make 1Password less secure (the regression that occurred from 1Password 4 --> 7 never would have happened with this metric). Only changes that have no affect to security and those that improve security should be allowed to be entered into the product.
Like it or not Agilebits, 1Password is a security tool. If that's not the way you view it (comments to that effect have been made by Agilebits employees in this thread), then you've been misleading us and those of us commenting here because we care about this product as much as you do need to move on to other options.
No, I fully realize you aren't AV or a tool that will make my computer super safe all by itself. But up until the other day when this report came out, I was confident that my passwords were completely locked up tight when I locked my computer and 1Password locked. I think I speak for every customer here - this news greatly disappointed us.
Enough excuses. Fortify every hole. Fill every gap. Your job is to keep our passwords safe.
Here's an idea - walk into the conference room on Monday morning and write "COMPROMISED!" on the white board. Ask your staff - what do we need to do to make 1Password not leak passwords on a compromised system? Brainstorm what it would take to do - no matter how outlandish the requirements might be. No you won't be able to do it tomorrow, but start there and work backwards. That should be your ultimate goal.
Please no more excuses. Secure our passwords. Realize for the first time in probably forever - many here are starting to think about what other options are out there for password management, not just for ourselves, but for our businesses.
Security is all that matters with your business. Everything else be damned.
0 -
Hi @MikeT
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.
The BSOD dump generated by ISE researchers had nothing to do with 1Password participating in WER though, right? So while it's good that 1Password doesn't also send secrets, what's the value of the 1Password WER opt-out if another app that can access memory uses it?
These dumps are not sent by default as per Microsoft's docs here: https://docs.microsoft.com/en-us/windows/desktop/wer/collecting-user-mode-dumps
Windows:
Starting with Windows Server 2008 and Windows Vista with Service Pack 1 (SP1), Windows Error Reporting (WER) can be configured so that full user-mode dumps are collected and stored locally after a user-mode application crashes. Applications that do their own custom crash reporting, including .NET applications, are not supported by this feature.
The page you linked addresses only local storage of the dump, not sending it. If we shouldn't be concerned with 1Password keeping secrets locally because they're too hard to access, what difference does it make if Windows stores them locally? Does the last statement mean that Windows can't be configured to store full dumps for 1Password and other .NET apps, or that they follow some other default behavior?
Beginning with Windows Vista, Windows provides crash, non-response, and kernel fault error reporting by default without requiring changes to your application. The report will include minidump and heap dump information if required.
So Windows won't send a complete dump by default, unless it does due to, say, security policies within an organization?
https://docs.microsoft.com/en-us/windows/desktop/wer/wer-settings
Is this behavior any different in Windows 10, since it isn't specifically addressed here?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.
@jpgoldberg So far, we get a new rec every day from your team about user actions to minimize risk from this known, old vulnerability, that really isn't that big a deal except when it is (like sending a debug log). Your most meaningful responses to the ISE paper, on what we keep hearing was a known issue, have come piecemeal and don't seem entirely consistent with either your own or other team members' responses. Let's all agree you got caught on the back foot.
What else, besides 'shut down, don't run locked' or 'turns out your logs aren't just your Sonic Pinball saves and a browser cache full of cat pictures, don't ever let anyone get them' should we know in regards to keeping our data as safe as possible with 1Password, given its limitations? It seems that if we don't ask about specific vulnerabilities (and I'm sure most people wouldn't even know where to begin, which is why we pay you), we don't learn about them. What else do we not know? Why does the bug bounty program specifically exclude memory dumps, and do you think this had anything to do with why you only just became aware of Windows BSOD behavior?
0 -
Argument from 1password team: We know this issue from the moment we decided to choose the new programming language and it is a trade off in our view. Keeping system clean is user’s responsibility. 1Password should not run in a compromised system. It is not possible to clear the memory after use in the new language. So we are not going to do anything except doing some preliminary investigation into a new language which we do not promise to use.
In addition, I think this incident should ring alarms in your team on how security should be the number one priority and goal in the entire lifecycle of your software development, from choosing the frameworks and languages, to actual implementation on different platforms (decrypting everything upon unlocking is not a good implementation in security perspective). Your product is not just another app, it manages every digital secret of your user, and sometimes, it determines your users life and death.
I really hope 1Password take it more serious and start facing and addressing this issue immediately. Do not burry your heads in the sand and say we can’t do it and we don’t need to. Because you can, and you have to. There is no excuse.Very well put. The sheer size of this thread shows that a lot of people are concerned not because security issues pop up (just today there was a new Jailbreak for iOS 12), but because how these issues are dealt with (Apple is certainly already preparing a patch for iOS 12).
0 -
To people spewing invective about 1Password take a look at the LastPass forum.
Not a sausage has been said by LastPass staff - no official statement.
At least with 1Password you're getting direct developer feedback.
Even LastPass users are coming to the common-sense conclusion:
If a computer is compromised to the point where an attacker can read memory dumps, then you've got bigger problems.
and
This simply isn't a very realistic threat scenario.
0 -
@nikanorov Shutting down the system before crossing boarders is always a good idea. That'll clear memory, and in that case, the vault is locked. But as Bruce Schneier is fond of saying, no technology can prevent rubber-hose cryptanalysis from succeeding.
@alexyang Yep. Most banking malware does exactly that. And there's no way any password manager can stop it.
I will say this about AgileBits, from all my interactions with them, public and private, they do try to get security right. Remember when they took away the ability to share passwords via iMessage? That was done because it appeared secure when it wasn't. We argued a lot here in the forum that the tradeoff was ours to make, not theirs. They listened to the user base, and turned it back on - but with a modified UI that made it clear the risk. Likewise, they have kept local sync around for years because of vocal users (I used to be one) who needed it because of corporate policy or lack of trust in cloud services. It's all about risk and tradeoffs - including where to focus their limited development resources.
This is a complex problem, with nuanced threats and mitigations. Is it a vulnerability? Yes. It is directly exploitable (i.e. without another vulnerability)? No - it takes a compromised machine (either physical or via malware). Are chain exploits a possibility? Absolutely. Did the bad guys already know about this vulnerability? Maybe. Do they now, and will they try to exploit it? Likely. Is complete mitigation possible? No, not in a modern OS. Can it be mitigated through code changes? Partially, and it should be to the extent it doesn't introduce more severe vulnerabilities. Will that be a complete mitigation? No, there will be residual risk. Is the UI misleading? Yes - and that should be fixed, either by changing the UI or mitigating the vulnerability. In the meantime are there other mitigations for it? Yes (as I outlined above).
On that last, let me add one more. Windows, MacOS, iOS and Android all have very different levels of 'practical exploitability' for this one. A current iOS device is likely to be very difficult to exploit short of nation-state/law-enforcement level forensic tools and physical possession of the device. Android is easier, but if it's current and you only use Google-store apps, it's still pretty darn solid. MacOS and Windows are the big risks, particularly windows because there's a much wider range of threats and exploits that could be chained together with this vulnerability. So, while it would be painful, you could access your vault on iOS and then manually type in the password. Credential stealing malware would only be able to get the ones you use while it's persistent on your machine. Using MFA, with a OTP that's not via SMS (wow acronym city EIEIO) would probably stop that in the tracks.
I think from a business standpoint Agile will need to do something sooner rather than later, regardless of the actual probability of exploit because a nuanced dialog about risk isn't an option for the wider user base. Besides, if they don't, and there is a data disclosure down the road - even if not directly related to this (the press is notorious for getting details of breaches wrong), it'll be significant repetitional damage to their brand. If I were consulting with them, I'd counsel that LML is now a top development priority for Windows and MacOS.
0 -
@arabbit points out that
we get a new rec every day from your team about user actions to minimize risk from this known, old vulnerability, that really isn't that big a deal except when it is (like sending a debug log). Your most meaningful responses to the ISE paper, on what we keep hearing was a known issue, have come piecemeal and don't seem entirely consistent with either your own or other team members' responses
This variability is a consequence of us participating in open discussion. The alternative would be for us to say nothing while we study the problem fully over the course of several weeks and then issue a final statement. As should also be clear from some of my own corrections, I have learned some things about Windows which I didn't know before (or which I needed reminding about.) I have also tried to explore and learn from some of the helpful suggestions that have been made.
There are also going to be different views about threats. As I said somewhere or other, when it comes running on compromised systems, our threat model is fuzzy. We can't defend against all and arbitrary local compromises, but there are some that we reasonably can and should defend against. But we don't have a well defined official list of which we do and which we don't when we get into that fuzzy area.
Furthermore, my own views on some of this stuff have changed during this discussion. In particular, I now believe that just because we can't guarantee that garbage collections will quickly do what we want it to do, we really should have done much more to at least release secrets upon lock. We've actually had a plan for this sketched out (at least) two years ago. I need to look (mostly at myself) for why this wasn't worked on in those two years. So yes. You are not getting one specific, consistent response. And we haven't worked out what reasonable and actionable1 user advice we should be. And as I've mentioned before, our focus is on calming the over-reaction. (There are a lot of people who somehow don't realize that an attacker has to at lead get some footing on the machine.)
We could have silently gathered information, set up an internal team to investigate, and only after running everything through a committee issued a statement. And so all you would be hearing now would be "no comment" and a few vague reassurances massaged by a marketing team. Instead, we are far more actively engaging in and learning from this public discussion.
Let's all agree you got caught on the back foot.
No argument there.
-
I hate the word "actionable", but it seems to actually be the right word here. ↩︎
0 -
-
We could have silently gathered information, set up an internal team to investigate, and only after running everything through a committee issued a statement.
Do you want a medal? There's a whole lot of daylight between running silent for weeks and a situation where customers paying you for a product teach you about it/the OS. Assuming this is the best possible response, this is still valid criticism even though it isn't the worst route you could have taken.
What's the deal with the bug bounty excluding memory issues? Do you have a plan in place to identify other vulnerabilities/exploits in light of what you've learned from your customers? If not a timeline for fixing the UI and documentation, do you have a timeline for creating one? Where can we read more than the first page of your BugCrowd audit? What else do we not know about your product that you previously considered old news?
Traditionally, when someone takes responsibility for their actions, you don't also see repeated statements that customers are panicking, have an overblown response to being lied to, or insinuations that any discussion of the vulnerabilities other than your own amount to FUD. This sort of thing is disrespectful to the people who put food on your table and gives the strong impression you don't understand the way you treat your customers is just as important as the product you provide, if not more. So if you're going to keep coming back with half-answers wherein you pretend you've castigated yourself enough and gosh aren't we glad that's over, I recommend you seek the services of some PR people and/or get an attitude adjustment. Your response is the #1 reason you will never see another dime from me.
0 -
@arabbit I actually prefer this kind of response - devs are replying themselves in detail and are seemingly updating their positions. Arriving at a reasonable plan does take longer than a few days, especially if you need to commit to it publicly (ignoring the fact that it should have been started a couple of years ago :)). With any luck they will gather a few more threat scenarios from posters here -- you can't do that without active conversation.
PR people would shut this down faster than you can leak all you passwords on a windows machine and all you would get is a vacuous canned corporate statement.
0 -
I think you guys are making this a lot harder than it needs to be. Look at what keeper does:
https://keepersecurity.com/blog/2019/02/20/ise-research-study-response/
When Keeper users click on “Logout” from their Keeper Desktop application, we perform an app reboot to ensure that the processes which contained data in memory are completely cleared. This includes the Master Password, 2FA tokens, stored vault data and any encryption keys required to decrypt user data.
For the sake of your business, ship this next week. This will buy you time to implement Rust and LML properly.
0 -
@dougl Not all actions of a malware can be prevented, but 1password is designed and implemented in a way that makes stealing passwords incredibly easy. It exposed ENTIRE vault once unlocked, and did not clear anything in any way after lock or auto lock. Meanwhile, it doesn’t require any admin privileges for the malware to read it’s memory, so users will not have any chance of knowing that their password would be stolen. That’s the real threat. If a program can launch without admin rights, read the memory and exit, it doesn’t even need to be persistent on the machine. Unlike daemons, it does not need to stay in the background, and thus minimise the chance to be detected by user or antivirus.
0 -
Support @Charlie_s suggestion here, please look at what Keeper has done @jpgoldberg.
0 -
The change from C to higher level programming language was also intended to prevent the exploit of memory issues occurred on the device. But such exploit would only succeed if there are memory issues caused by bugs in the app, whereas the current approach just gives the same information away at no cost.
0 -
All,
Apologies if this is on a tangent to this--what seems to be an--almost entirely Windows centric discussion. And, I know about Windows' dominance. However, earlier, I inquired about the extent to which this all applies to MacOS and iOS. There was a response (copied below) that briefly suggested (especially when revised) that some/much/most of this long thread does NOT/NOT apply for MacOS/iOS.
Am I reading this right? And/or could someone from AgileBits say affirmatively how/why this is/is not the case? (Doesn't need to be long, but the short amendment that came yesterday is the kind of thing I'm thinking of.)
Thanks,
ToddRESPONSE:
John, in principle we have the same issue on Mac, but in practice these things play out differently. It appears that these do get cleared from memory faster on the Mac. Some of this can be attributed specific design, some to automatic reference counting versus garbage collection, and some operating system environment.We were more concerned about this on Mac when DMA attacks were a thing. But fortunately that environment made it easier to make progress on this. But some of the fundamental issues remain. We need to use Apple’s SecureInput for Master Password input, which is an immutable string, but for some reason when we say we no longer need that data it gets cleared from memory relatively quickly. But that is not something we can guarantee in any way.
I have since been informed that SecureInput on Apple devices does everything we want. Sure it gives us an immutable string, but it is actually zeroed in memory as soon as it is freed, and it is written a page in memory that is never written to swap.
0 -
There was a response (copied below) that briefly suggested (especially when revised) that some/much/most of this long thread does NOT/NOT apply for MacOS/iOS.
Am I reading this right? And/or could someone from AgileBits say affirmatively how/why this is/is not the case? (Doesn't need to be long, but the short amendment that came yesterday is the kind of thing I'm thinking of.)
I'm not working for Agilebits, but I did take some time to look into the issue.
If you are running macOS Mojave with System Integrity Protection (SIP) enabled and 1Password 7.2+ you should be fine in terms of the bare vulnerability. While 1Password still does leak passwords into memory and is unable to easily clear them out when 1Password is locked, the memory subsystem in macOS is pretty robust. What this means in practice, is that unless some other memory vulnerability is found, there is no way to read the memory of 1Password, even with privileged access using just software. Even if your computer or browser is compromised, it would not be easy to read the passwords out from 1Password memory. Monitoring the clipboard and other related vulnerabilities still apply when having privileged access to a computer, but a plain memory read should be fairly difficult.
This does not mean that you're exactly safe, some DMA attacks and other things may apply, as well as someone disabling SIP (which requires a reboot into rescue mode) can of course make the passwords in memory readable again. But these are much harder attack vectors than what the Windows version is currently experiencing with non-privileged memory dumps.
0 -
@tesmi: Thanks for your comments. That seems like a fair summary. :) Indeed, the OS and frameworks are very different between OSes, so the threats (and challenges) are different as well. SecureInput, SIP, Gatekeeper, etc. are really beneficial to users, even if they can be a pain sometimes to developers. ;) None of these things offer protection against all possible threats, but each do a good job of protecting against specific classes of attacks, and in concert can make a big difference.
0
![[Deleted User]](https://w8.vanillicon.com/v2/87d6bf4bcda1274e7d83320d05f0c74a.svg)
