We've talked about this several times, most recently was in June. Please see https://blog.agilebits.com/2015/06/17/1password-inter-proces...
This falls into the question of what can we do to prevent attacks from malicious processes running on the user's machine. For the most part, we do try to defend against something where we can. For example, we take steps to make key logging a little more difficult.
In this case, the steps (other than mere obfuscation) that would be necessary to properly encrypt that channel would require that the user be confronted with a "pairing" request and prompt almost every time they restart their browser.
Again, it would be easy to obfuscate this communication, say by using wss; but the private key for that server would still need to be stored en clare on the computer.
There are other approaches as well, but all have unpleasant side effects that risk user data in other ways.
>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.
Why every time? The first time, yes, and then each side stores its key. Future connections must handshake on that shared key, so you aren't talking to an imposter.
You still lose against root malware, but threat still seems to strictly decrease.
Encrypting with a key that is available to attackers (who have the same set a privileges needed to run localhost sniffing) is not encryption. It is obfuscation.
For example: https://paragonie.com/blog/2015/09/comprehensive-guide-url-p...
What do you need to do before you can sniff a loopback interface?
Thank you for responding. The reason I wrote this up is not to let people oh my god the world is ending but to let them know, hey if you are using the browser extension there is clear text passwords being sent over the loopback, if you don't like that then don't use their extensions.
You have made very well informed arguments about how hard it is to protect if someone has access to your machine, specifically elevated. But the argument to me seems kind of like "well, it's hard to protect against then so we just decided to not do anything at all." It seems like one other password manager company did something, so why wouldn't you?
Can you explain why it would require a pairing request every time? Couldn't you just pair it once and then be done with it? Can you explain the other approaches?
You are asking 1password to fix a non-issue. Sniffing loopback requires root privileges on the machine. If someone can sniff loopback, they can just as easily reach directly into the 1password processes's memory and extract the password from there, or replace 1password with a malicious extension that sends all your passwords to the attacker, or just log your keypresses. These other strategies may actually be easier than sniffing loopback. There is no reasonable defense against an attacker with root access, and encrypting communications over loopback would be a complete waste of effort and CPU time.
Honestly I feel bad for 1password that this article insinuating a security issue in their product is trending on HN when there is in fact no issue (as far as I can see, from the information presented).
If you only want to pair it once then you will need to store the pairing secrets somewhere. Since both server and the client are running on the same machine, it is going to be trivial to obtain this information.
Re: other password managers did something. It must have something to do with the disdain for obfuscation that we had for a long time. Encryption is good, obfuscation is a lie. We always felt if we obfuscate something then we will be lying to everyone. I am not blaming anyone and concede that our position might be a bit naive in this case.
I really really don't like talking about how our competitors might do things. (I work for AgileBits, the makers of 1Password). But I can talk about why we picked one security design over a plausible alternative. So here goes.
One way such a system could work is that the browser extension could talk to a process on the provider’s server. Because the server is remote, the TLS secret key would be stored on that remote server, and so would not be accessible to a root process running on the user’s system. This would, indeed, solve the IPC issue as there wouldn’t be any IPC.
There are a few reasons why we don’t operate that way. To operate that we we would end up knowing when and where our customers log into things. But we don’t want to be in a position to learn our customer’s shopping habits or whether they log into ISecretlyLoveNickelback.org. But with the client server model of that way of doing such things, we would be getting lots of that kind of information and holding on to some of it unencrypted.
Similarly, we don’t want to store any information that if stolen from us would enable such a thief to try to make cracking attempts at people’s Master Passwords. Sure PBKDF2 is good, but it only provides temporary protection should the data be stolen. We also don’t want “big” secrets in the browser. Our browser extension never sees your Master Password and only ever has the password for site it is filling for (or learning from). We see the browser as a very hostile environment.
Now there are certain ways around some of those things. And again, I’m not making any claim about how any other product does things. I’m only discussing how a service with the properties you describe might work.
Different security designs expose different sorts of threats. Nobody can really defend against an attacker running as root on their own system, but our more obvious exposure to to running on a rooted machine in this particular scenario is something that we think is worth the security and privacy benefits of our design.
[Note: I have plagiarized myself from https://medium.com/@jpgoldberg/ross-regarding-your-makes-you... as I'm being asked the same questions in different locations]
To pair it once would mean that a long term secret would need to be stored. Now we consider ourselves experts at storing long term secrets, but this one would need to be available to 1Password Mini and/or the browser extension even when 1Password is locked. So it would need to be stored on the local machine in a way that is not protected by 1Password.
So an attacker with root privileges (as needed for the loopback sniffing) would be able to get that key. And as I've said in various places throughout this conversation, "encrypting" something with a key that is available to the attacker is merely obfuscation.
We try to be very clear and open about the choices that we've made in our security design, why we made them, and what the implications for users are.
It's likely that I'm misunderstanding things here, but here's what I'm imagining:
* I use 1Password and presume that my plaintext password stays on my machine.
* I use HTTPS for traffic that I care to secure.
* I contract to a vendor, with whom I don't share trusted information, to provide a dumb (non-VPS) shell, which I use for a variety of purposes.
* Among these, I use a SOCKS proxy to VPN traffic for some reason (say, to circumvent state censorship). Again, I presume that the vendor in question can't read my HTTPS traffic or 1Password info.
Can't the vendor in this case, who presumably has root on the machine in question, now sniff the loopback and find my passwords?
If the answer is "yes," then it breaks the workflow of trustless use of a SOCKS proxy.
Hmm. I'm fairly sure we thought through that option, but at moment I can't see see/recall why we rejected it.
Clearly, someone at agile bits has given thought to defending against a compromised machine. Therefore, I don't see how you can justify not obfuscating data sent over lo0. I also fail to see how obfuscating the data sent over lo0 would "have unpleasant side effects that risk user data in other ways."
Also in order to populate the password/credit card fields at some point doesn't the information need to be decrypted? I'd be more concerned if 1Password was storing the keys to decrypt passwords in a browser plugin as that is a way easier attack vector
I did a little poking around for a threat model for 1Password, but I couldn't find one. Plaintext over loopback is only a problem for 1Password if (and only if) 1Password was intending to protect against machine compromise. Now, it's a little difficult to decide if that's the case, since they are encrypting everything locally, explicitly to protect against machine compromise, but is that compromise in case of eg. machine confiscation, or compromise in case of eg. local malware?
Presumably, 1Password isn't trying to address the latter case (and I haven't heard them say otherwise). And to be honest, I'm extremely skeptical that protecting against machine compromise is something you can do at anything other than an operating system level, especially for anything involving IPC (like 1Password).
Edit: I'll defer to jpgoldberg's comment above. [1] They've made a risk/benefit analysis decision on handling IPC that it's too difficult to secure, and that effectively any security for the IPC to browser would be 1) functionally meaningless to a targeted attack, like obfuscation, or 2) present undue burden to the people using the software. I'll +1 their analysis (they also have several blog posts on the topic); makes sense to me. “Once an attacker has broken into your computer, it is no longer your computer.”
Officially our view is "if a malicious process with user privileges is running on the users machine when they use 1Password, there is little we can do".
But sometimes we try to do better. The example I raise is the steps we take to make things harder for keystroke loggers. We won't go to extraordinary measures to enter a battle that we can't win, but when there are simple things that we can do to make things harder for malware, we will.
See the first three paragraphs of https://blog.agilebits.com/2014/08/21/watch-what-you-type-1p... for some sort of attempt to clarify our vagueness about this threat model.
Short of that level of extreme misconfiguration, you need admin, which means all bets are already off as you can keylog, inject libs, patch the executable, whatever you please really.
They could do more to protect this, but anything more would be a half-measure of no real use against a targetted attack at least.
You need the password to be "plaintext" in the input field in the browser, so how do you get it there?
Give the extension access to your private keys and master password to do decryption there? Is the browser a safer environment than an app on your machine?
I use saslauthd in a web server I wrote. I have the user ID and password from the browser over HTTPS, open a socket to /var/run/saslauthd/mux, and send them as plain strings, then check the reply.
The problem with loopback is that the only thing which prevents the program from sending the data to a rogue socket is the IP address and port number.
If I have some program binary which authenticates plain text passwords over an IP socket, I can probably find the "struct sockaddr_in" image of that address and change it to something else with a hex editor, to have that communication go to another machine. I'm not saying that this is the exact exploit; that would be a strawman: rather that there is potentially a very small code or configuration difference between a secure program that sends plain text over an IP socket, and a misbehaving one.) Of course, the path in a unix socket could also be tampered with; at least it won't go off box, though. The rogue piece listening to for the connection has to be planted on the same machine.
Also, code signing would prevent anyone from modifying the binaries to change the IP address.
As for the solution, without thinking too much, using TLS to encrypt the channel would do it. If we think the browser is not safe, well, all your stack is basically compromised. But if it could handle TLS correctly (and I guess it does it pretty well since it use it to send the info to your bank) it could get the password in a sfae way...
Obfuscation would mean that we wouldn't have to have this conversation as often as we do. But it would not make our customers more secure.
So, if you could sniff this, you'd have elevated privs anyway, which means you could read the keyboard device, memory, etc.
Not ideal, but not sure it's a glaring hole. IMHO. I'd love to hear other thoughts on how to exploit this / how I'm underestimating this hole.
After that, assuming the transmission has to happen, it's just a matter of how difficult you want to make it for root to see the passwords. Since you have to arrive at plaintext in the browser itself, everything a determined root needs to decrypt the transmission will be present on the machine anyway. Still, even a simple ROT-13 to keep an honest root from accidentally seeing the password would be welcome.
I just tried it, and with Chrome and 1Password, I was able to see my auto-filled bank password in the pcap. So, I presume any process on my system, without root privileges, would be able to sniff loopback.
I don't see why 1Password wouldn't use TLS here. This is not good.
> $ tcpdump -i lo0 -s 65535 -w info.pcap
tcpdump: lo0: You don't have permission to capture on that device
((cannot open BPF device) /dev/bpf0: Permission denied) $ tcpdump -i lo0 -s 65535 -w info.pcap
tcpdump: lo0: You don't have permission to capture on that device
((cannot open BPF device) /dev/bpf0: Permission denied)
I don't really see what the vulnerability is here.
That's the big issue, I think, unless I'm missing something.
Either way, I don't think this is 100% responsible disclosure.
The author gives his justification for full disclosure in the last paragraph. As I wrote yesterday [0], opinions vary regarding "responsible" disclosure -- and the "discoverer" gets to decide how he wants to handle things.
https://blogs.msdn.microsoft.com/oldnewthing/20060508-22/?p=...
https://gist.github.com/joevennix/438782cbe447e86f2506
It would be more interesting if an arbitrary website could do this, but they prevent that attack by checking the Origin header on the initial websocket request.
This is a complete non-issue.
I'd like to understand better to know whether it a similar issue affects LastPass. Though at least with LastPass we're able to use the browser extension without having the native app. I don't think that's possible with 1Password for Mac.
I use this in a web service to authenticate users. The form containing the password is submitted over HTTPS. The CGI script opens the socket, and sends it to saslauthd, which replies OK or not.
That means also apps installed by a person who has access to your systems or malicious code that you, or someone who as access to your system, launched on your system. I'm not sure where it put 1Password in terms of safely storing password, but it is probably in the area of a post-it on your monitor.
I don't know what's your opinion, but if I use a password manager, I'm expecting something more
Every app that runs on your systems with enough privileges can dump the memory and extract information via that.
1Password responded in a blog post here https://blog.agilebits.com/2015/06/17/1password-inter-proces...
If you have loopback sniffing privileges, you could just also ReadProcessMemory the password right out of 1passwords memory.
But the moment you trust the password to a compromised computer, it's game over.
Two reasons we don't use unix domain sockets are: 1) they are not cross platform 2) they can't be created by browser extensions
So it is not making safe situation bad, but bad situation worse. Of course with Blizzard Warden, Steam anti cheat, driver level firewalls and all the other little helpers that collect information about your system - this could lead to a leak to some entity's logs in the cloud.
Your second point is spot on though I think, one would need to own the machine already before being able to sniff loopback.