7 ms·
1Password sends your password in clear text across the loopback interface
- marvel_boy 11y agoWow, the communication should be encrypted.
- draw_down 11y agoSeems bad!
- slavik81 11y agoWhat's wrong with that?
- eugenekolo2 11y agoLike 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.
- venomsnake 11y agoYour firewall vendor knowing all your passwords? Nothing. And that is the most benign entity that could listen on the interface.
- LukaAl 11y agoEvery 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
- matthewmacleod 11y agoI don't see how the situation you describe is avoidable, while retaining the ability for a user to automatically fill form fields. That inherently means that the password will be unencrypted and stored for some time; what's the practical difference between sending it via loopback and any other method?
- afreak 11y ago> Every app that runs on your systems with enough privilege could sniff your username and password and send it out. Every app that runs on your systems with enough privileges can dump the memory and extract information via that.
- aidos 11y agoI'm not sure what the implications are. What has access to that information? Is it public to all services on the machine? Either way, I don't think this is 100% responsible disclosure.
- jlgaddis 11y agoAnyone 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. [0]: https://news.ycombinator.com/item?id=11206955 https://news.ycombinator.com/item?id=11206955
- matthewmacleod 11y agoMaybe I'm not understanding fully how this works, but couldn't any user with administrative access already gain access to this information anyway? It's obviously got to be stored unencrypted in the browser's memory, regardless of how it gets there; I'm not sure what the difference is here.
- jlgaddis 11y agoThey could, sure, but this lowers the bar, I think. It's a helluva lot easier to simply fire up a packet capture for a few minutes and grab the credentials from that than to go sifting through all the gigabytes of RAM for the credentials.
- cortesoft 11y agoI don't think you even need administrator access to the machine. The ports being listened to aren't protected ones, and the process is running as the regular user. Any process running as that user could kill the other process and bind to those ports.
- isleyaardvark 11y ago
- fixermark 11y agoSo 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.
- venomsnake 11y agoIf 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.
- msbarnett 11y agoYou 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. This is a complete non-issue.
- jMyles 11y agoI'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?
- deleted 11y ago[deleted]
- deleted 11y ago[deleted]
- s800 11y agoAt least on OSX 10.11 (not sure about others), you can't sniff loopback as a normal user. 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 11y agoThere is no modern OS on which you can sniff loopback without privileges.
- cortesoft 11y agoRight, but it looks like the process listening on the port is running as the user.... what is to stop another process running as the same user from killing that process and then binding to the same port?
- tptacek 11y agoNothing, but if you own the user's account, you also have their /Library directory to play with.
- richard_todd 11y agoRight, 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.
- tonywebster 11y agoThe 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.
- JonathonW 11y agoEncrypted 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.
- jlgaddis 11y agoIn a corporate environment, a system administrator with administrative access to employee/user machines could gain access to their credentials. That's the big issue, I think, unless I'm missing something.
- tptacek 11y agoThey can do that anyways by sniffing the keyboard directly.
- pfg 11y agoSomeone with administrative access would have an almost unlimited number of ways of accessing passwords in any password manager. Key logging, memory dumps ... once your system is owned, you're SOL.
- jlgaddis 11y agoI agree, but this makes it a helluva lot easier.
- jish 11y agoSerious 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?
- deleted 11y ago[deleted]
- jlgaddis 11y agoThey could at least encrypt it across the socket.
- euroclydon 11y agoHow is the encryption key supposed to get into the Browser plugin?
- LukaAl 11y agoSame way as the encryption key used to secure the communication with your bank. It doesn't. The idea behind TLS is that the client and the server agree on a temporary key to exchange the information in a secure way (there's a ton of literature on it) without saving the key locally. The good news is that it is something already implemented in a safe way in all sufficiently recent browser (for sufficiently recent I mean, sufficiently recent to support plugins, because also IE 6 supports some old form of SSL) and make them available to plugins. TL;DR: It's trivial to do it right, screwing it up in this way means they have no clue on what security means.
- jeeyoungk 11y agoIn this case, client = server. If your computer is compromised then they can get access to both private and public keys of 1Password and 1Password Mini. It also doesn't prevent MITM unless both the client & server. Nothing stops you from presenting a fake public key pair between the communication How doe TLS work then? Because public keys are signed by central authorities. Who do we know what to trust? Browsers and OSes have default list of certificate authorities to trust. How do we know that we can trust them? Technically they should be communicated outside the internet. If the version of Chrome you download is compromised with a rogue certificate authority (ex: SuperFish) then you're hosed. It's turtles all the way. Unless keys are communicated securely somehow you cannot guarantee secure communication.
- deleted 11y ago[deleted]
- rolfvandekrol 11y agoIn 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'?
- khad 11y ago12 hours.
- watson 11y agoHe 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
- venomsnake 11y agoThat 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.
- elbigbad 11y agoI 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.
- venomsnake 11y agoSending in plaintext is sloppy. You can have any protocol over loopback.
- jpgoldberg 11y agoAnd where would you store the keys for that communication in a way that an attacker with root privileges couldn't get it? "Encrypting" with keys available to the attacker is mere obfuscation. In this case, it would provide no extra security to customers; all it would do is lead them to believe that something is encrypted when it is merely obfuscated.
- julie78787 11y agoExcept that you can attack stored encryption secrets either off-line, or with the same privileges as the user. If they are hard-coded in the binary, they can be extracted off-line by another use with the same binary. If they are generated at run-time, they have to be stored with permissions that grants the user access to their own resource. There are programming techniques for sharing a file descriptor, but they aren't portable. That makes generating a keypair, then sharing an open file descriptor to the file containing the keypair impossible.
- 4doorsaloon 11y agoI believe this is the same issue that AgileBits has been aware of for some time. https://blog.agilebits.com/2015/06/17/1password-inter-process-communication-discussion/ https://blog.agilebits.com/2015/06/17/1password-inter-proces...
- euroclydon 11y agoWhile 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.
- dcole2929 11y agoBy 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
- tptacek 11y agoNo, it is not exploitable.
- ultramancool 11y agoYeah, at worst a misconfigured system where non-root users have access to sniff it could be attacked. 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.
- venomsnake 11y agoBut could it leak something - lets say antivirus or firewall with heuristics picks up the traffic and sends it for analysis?
- tptacek 11y agoDon't install antivirus software on OS X. Who knows what crazy shit it might do to your system?
- mixedbit 11y agoIn general it depends on the protocol that is used for communication. If it for example were not authenticated HTTP, it could be remotely exploitable by a website that a user visits.
- deleted 11y ago[deleted]
- jtth 11y agoThis is stupid.
- tptacek 11y agoSo what?
- vbezhenar 11y agoI'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.
- rdl 11y agohttps://blog.agilebits.com/2015/06/17/1password-inter-process-communication-discussion/ https://blog.agilebits.com/2015/06/17/1password-inter-proces...
- revelation 11y agoIf 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.
- nikolay 11y agoIf this was an easy task to tackle, we wouldn't be paying a commercial entity to take care of it.
- revelation 11y agoYou're not understanding. The only solution to this "problem" is to not give the computer access to the password, which defeats the purpose. But the moment you trust the password to a compromised computer, it's game over.
- nikolay 11y agoNo, I understand, but it looks like browsers can tackle this better than any third-party could unless there's a plugin mechanism just for that purpose.
- uptown 11y agoDo 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.
- jpgoldberg 11y ago[Disclosure: I work for AgileBits, the makers of 1Password] We've talked about this several times, most recently was in June. Please see https://blog.agilebits.com/2015/06/17/1password-inter-process-communication-discussion/ 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 11y agoSurely 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.
- CiPHPerCoder 11y ago"Let's throw encryption at the problem" isn't always wise. For example: https://paragonie.com/blog/2015/09/comprehensive-guide-url-parameter-encryption-in-php https://paragonie.com/blog/2015/09/comprehensive-guide-url-p... What do you need to do before you can sniff a loopback interface?
- kazinator 11y agoThe 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.
- ikeboy 11y agoOn a quick look this seems to be the same as the vuln discussed in http://arxiv.org/abs/1505.06836 http://arxiv.org/abs/1505.06836. 1Password responded in a blog post here https://blog.agilebits.com/2015/06/17/1password-inter-process-communication-discussion/ https://blog.agilebits.com/2015/06/17/1password-inter-proces...
- joev_ 11y agoI mucked with this a while back. You can dump all your passwords over the websocket pretty easily (provided your 1password is unlocked): https://gist.github.com/joevennix/438782cbe447e86f2506 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.
- city41 11y agoOn 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.
- tedmiston 11y agoIs 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.
- detaro 11y agoGeneral 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.
- bwoodruff 11y ago[full disclosure: I work for AgileBits] 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
- hoechst 11y agoFor 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).
- Negative1 11y agoIf someone is observing your loopback isn't it just as likely they're keylogging and have your 1Password master keyphrase?