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.
Surely encryption with a shared key is strictly better than sending in plaintext?
>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.
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?
> This falls into the question of what can we do to prevent attacks from malicious processes running on the user's machine.
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.
FTA "the 1Password browser extension protects you from a more typical malware attack of pasteboard/clipboard sniffers."
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."
By no means an expert but is this even exploitable if the machine is not already otherwise compromised? Loopback is used for communication between two network applications on the same machine but it doesn't actually use the network device. Of course you'll be able to see it listening on your own computer but an outside computer can't sniff something that doesn't actually get transmitted over the network.
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
You're correct, the loopback works as you described. You should never see loopback packets anywhere but the host machine; if you do, that machine is compromised (not necessarily maliciously, but it's not working how it's supposed to be).
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.”
Serious question: Why is this a bad thing, and how would you do it differently?
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 would gravitate toward using a Unix domain socket, like what saslauthd uses.
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.
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...
Right, if you can watch loopback as a normal user, then the biggest problem is with machine configuration.
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.
The author used `tcpdump -i lo0 -s 65535 -w info.pcap` which, as a non-root user without sudo, successfully captures loopback traffic in OS X 10.11.3.
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.
Encrypted or not, if 1Password is sending passwords to the browser extension, that means its keychain is unlocked and malware, should it really want to grab data out of the keychain, could just request it from the 1Password helper itself. No need to passively sniff for passwords.
I don't really see what the vulnerability is here.
In february 2015 I had contact with agilebits at support@agilebits.com and they answered me within a day. Seriously, you claim you tried to reach them, but I have a hard time believing that. What is 'not too long ago'?
He only claim he send them an email and that he then decided not to wait for an answer and publish this before they got a chance to respond. In no way is this acceptable behaviour from any security professional. In my mind he's just a kid who thought he would get some cheap points for discovering some big security issue but in the heat of the moment forgot to follow normal protocol
Anyone with administrative access to the machine could run a capture on the loopback interface and gain access to the plain-text passwords. It's certainly an issue, albeit a limited one (the same user could sniff your keystrokes, etc.).
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.
I'm trying to understand when this can be a problem. I guess if you are sharing a VPN / socks proxy with multiple people? And then they are sniffing the loopback and catch your plaintext? Or something?
Do other browser extensions have the ability to look at this data? Could a malicious extension have the necessary permissions to read the loopback interface data? Seems like if the 1Password extension has access, I'm not sure what would prevent others from exploiting that access as-well.
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.
I'm very skeptical of any attempts to secure already compromised machine. It's just unnecessary complications for user, bloat for software and determined attacker is likely to overcome them anyway.
So how vulnerable is loopback on a machine in general? This is almost certainly not a best practice, but I can't help but wonder how practically exploitable this is.
You need superuser privileges to sniff the loopback. Which means if you're in a position to exploit this, you could just sniff the keyboard, or do any number of other malicious things instead.
If I already pwn your machine I can learn your passwords while they are moving. So - it will require a special target for the exploit to be worthwhile - lets say North Korean general that uses the same password for pornhub and nuclear launch. That is protected by 1password.
Is this post about the 1Password browser extension communicating to the Mac app?
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.
The SASL authentication protocol sends cleartext passwords across a local UNIX domain socket. That's very similar: local IPC.
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.
Like a lot of security researching blogs, this post doesn't have a good conclusion. This seems bad, and probably is bad, but there has to be details as to why it's bad, what is the danger, what is the threat model, etc.
Every app that runs on your systems with enough privilege could sniff your username and password and send it out.
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
If you can't trust your system, there is no point in encryption. There is an innumerable number of ways an attacker can get your password if you assume the attacker has system privileges.
If you have loopback sniffing privileges, you could just also ReadProcessMemory the password right out of 1passwords memory.
For the record, as it's been asked in the blog post: Enpass uses loopback as well, but encrypts or decodes (obfuscates?) the data somehow. I looked into decoding the data, but I wasn’t able to do it (just tried for half an hour).
General question: why is it so common to use loopback, vs unix domain sockets? I haven't seen the latter used outside of mail infrastructure, and they seem slightly more secure to me regarding who can connect to them.
On a side note I find 1Password Mini makes the browser extensions irrelevant. I think the extra steps that Mini requires are not a big deal, and you get a smaller surface area.
While we're talking about 1Password: Why do they obscure the text editing area while I'm typing, but then de-obscure it when I'm done typing? The text I typed is visible when I'm done typing.
That is obviously sloppy work on the part of the developers. And bad. But anyone that can snoop on loopback already owns the machine and he could just cheat engine the passwords from the browser ram.
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.
I have a problem with the phrase "obviously sloppy work on the part of the developers." How exactly does one avoid loopback in an application like this?
Your second point is spot on though I think, one would need to own the machine already before being able to sniff loopback.
jpgoldberg|10 years ago
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.
ikeboy|10 years ago
>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.
nullrouted|10 years ago
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?
jMyles|10 years ago
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.
ihuman|10 years ago
bm5k|10 years ago
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."
nikolay|10 years ago
[deleted]
dcole2929|10 years ago
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
nbadg|10 years ago
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.”
[1] https://news.ycombinator.com/item?id=11212318
tptacek|10 years ago
jish|10 years ago
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?
kazinator|10 years ago
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.
LukaAl|10 years ago
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...
unknown|10 years ago
[deleted]
jlgaddis|10 years ago
s800|10 years ago
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.
tptacek|10 years ago
richard_todd|10 years ago
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.
tonywebster|10 years ago
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.
rdl|10 years ago
JonathonW|10 years ago
I don't really see what the vulnerability is here.
jlgaddis|10 years ago
That's the big issue, I think, unless I'm missing something.
rolfvandekrol|10 years ago
watson|10 years ago
khad|10 years ago
aidos|10 years ago
Either way, I don't think this is 100% responsible disclosure.
jlgaddis|10 years ago
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.
[0]: https://news.ycombinator.com/item?id=11206955
draw_down|10 years ago
4doorsaloon|10 years ago
jMyles|10 years ago
unknown|10 years ago
[deleted]
uptown|10 years ago
joev_|10 years ago
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.
vbezhenar|10 years ago
fixermark|10 years ago
msbarnett|10 years ago
This is a complete non-issue.
venomsnake|10 years ago
tedmiston|10 years ago
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.
tptacek|10 years ago
kazinator|10 years ago
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.
slavik81|10 years ago
eugenekolo2|10 years ago
LukaAl|10 years ago
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
venomsnake|10 years ago
ikeboy|10 years ago
1Password responded in a blog post here https://blog.agilebits.com/2015/06/17/1password-inter-proces...
unknown|10 years ago
[deleted]
unknown|10 years ago
[deleted]
revelation|10 years ago
If you have loopback sniffing privileges, you could just also ReadProcessMemory the password right out of 1passwords memory.
nikolay|10 years ago
hoechst|10 years ago
detaro|10 years ago
bwoodruff|10 years ago
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
city41|10 years ago
Negative1|10 years ago
jtth|10 years ago
unknown|10 years ago
[deleted]
draw_down|10 years ago
euroclydon|10 years ago
marvel_boy|10 years ago
venomsnake|10 years ago
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.
elbigbad|10 years ago
Your second point is spot on though I think, one would need to own the machine already before being able to sniff loopback.