1Password sends your password in clear text across the loopback interface
medium.com[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-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.
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.
The browser would have to hold on to the shared key long term. Where does it put this?
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.
I thought the point of the arxiv paper was that a non privileged app could effectively "sniff" by pretending to be the other app.
If I'm understanding correctly, that means that encrypting with a shared key helps. Am I missing something?
1Password verifies the code signature of the apps connecting to the WebSockets server using SecCodeCheckValidity.
That would prevent connection from the apps that do not have their code signature whitelisted.
From the paper:
>WebSocket. WebSocket servers are typically built over a few popular opensource frameworks, such as CocoaHTTPServer [3] and QtWebKit [14]. All of them provide a receiver method for getting messages from browser extensions, which is used by Xavus to fingerprint this channel, and a response method for replying to the extensions. The invocations of these two methods are identified as the claim and the use of the channel, respectively. Between them, the server is supposed to access the HTTP header Origin that includes extension IDs attached by the browser and check the signature of the browser through the API SecCodeCheckValidity. If these operations are not found, the app is considered vulnerable to the threat from a malicious extension or app. On the other hand, the attack from a malicious server against an extension cannot be detected through any existing APIs.
This sounds to me like the app validates the extension, but the extension can't validate the app. In that case, using a shared key helps.
Not if the shared key is present in the host computer already, which it'd have to be if the host process is to decrypt anything.
http://arxiv.org/abs/1505.06836
Other non root apps can masquerade as the app intended to get the data, and if it's sent in plaintext, they get information they wouldn't if it used a shared key accessible to the intended app.
Particularly if someone is specifically targeting 1password, which they (almost by definition) already would be. It'd just be a single patch to the exploit and you're back in business. Well, okay, obviously that's an oversimplification, but it wouldn't do you much good regardless.
But then malware must run as root.
Not necessarily. Malware only requires privilege if it is violating a security policy. There are a variety of attacks in which a process executing as a user is able to access resources controlled by other processes which are executing as the same user.
"Let's throw encryption at the problem" isn't always wise.
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?
http://arxiv.org/abs/1505.06836
You can run as a regular user (or even sandboxed) and connect to the interface without authentication.
Author here:
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?
I am not affiliated with 1password, but I am a security engineer.
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).
It doesn't always require root privileges...for instance if some program (wireshark) changes the permissions on your loopback. There are other questions there but I'll probably dig into it later.
The thing I guess I would say bothers me about your post is you just say well, if a person gets access to a machine it is basically all over which isn't necessarily the case. Even if they get root access we don't want to make it easy, right? Thats why we encrypt databases or in certain cases storage at rest so even if the hacker has root access it is sure going to be hard.
1Password can never absolutely protect against an attack when an attacker has root. But they can make it harder then just dumping out lo0. Level of effort does account for something.
> for instance if some program (wireshark) changes the permissions on your loopback.
That would be a serious security flaw in that program. Some program could also change the permissions on /dev/mem (or really any other device), with similarly disastrous results.
You can't expect 1password to defend you against other programs disabling the security of your operating system.
> if a person gets access to a machine it is basically all over which isn't necessarily the case.
Root access with ability to run sophisticated arbitrary code is game over, period.
Things that we should actually try to defend against (somewhat) include:
- A human briefly sitting down at your machine while you go to the bathroom. (E.g. Chrome's UI that allows you to display back your saved passwords in cleartext with no challenge is a legitimate security flaw, IMO.)
- Someone physically stealing your machine and then trying to dump the disk.
- Malicious software running without priviliges.
However, malicious software running as root is game over. Sorry, it is. Trying to make it hard for such software to do bad things is simply not feasible; there are far too many avenues of attack.
> Thats why we encrypt databases or in certain cases storage at rest
No, we encrypt data at rest to defend against physical theft of the storage medium, not to defend against live running processes that have root privileges.
If a malicious process has root, your encryption is meaningless. The key is in memory somewhere. The attacker doesn't really need to know where. They can dump the entirety of memory, and then cycle through it trying every N bytes as the encryption key and see if it works. This won't take very long!
You make some very good points. Question is, is there any way to know if such a malicious program is on your machine?
Maybe. Many will not hide themselves very well, but some use their power to make themselves invisible (often called a "rootkit"). I think the most promising approach to avoiding them is to use "secure boot" where the hardware verifies a signature on the firmware, which in turn verifies a signature on the OS, etc. ChromeOS devices (and some smartphones?) are pretty good at this. However, secure boot also prevents you, the rightful owner, from hacking (customizing) your own machine, which kind of sucks.
I am one of the 1Password developers.
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.
You've asked multiple questions. I'd like to give you a separate reply for each.
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]
I'm giving a separate reply to each of your questions. This is "Couldn't you just pair it once and then be done with it?"
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.
And now my reply to your first point. Thank you for letting people know that this interprocess communication is readable by something running as root on the user's machine. For those interested in this, please see an article we posted about this back in June: https://blog.agilebits.com/2015/06/17/1password-inter-proces...
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.
> 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.
The vendor does not have root on your machine or access to the loopback interface. Your machine's loopback interface should not be exposed through a SOCKS proxy unless you specifically tell it to do so (which is a terrible idea for reasons beyond just this situation).
I see. So the loopback traffic occurs on the local machine, the password is decrypted, and only then sent over the regular HTTP(S) connection (with this last bit being the only traffic on the SOCKS)?
Yes. Check your settings for your proxy to make sure you aren't sending traffic for localhost over the proxy.
(In Firefox, for example, it's excluded automatically.)
You can't just use some kind of Diffie–Hellman key exchange to agree on a key, instead of the user copying the key?
Are you suggesting simple DH without any long term secret?
Hmm. I'm fairly sure we thought through that option, but at moment I can't see see/recall why we rejected it.
Well, unauthenticated DH ("simple DH without any long term secret") is trivially MITM-able, so it could only be useful if you adversary could read but not write to the channel, which I doubt is the case in this context.
Right. This would be unauthenticated with all of the problems that that entails.
How would that work when both processes are running on the same Mac, under the same user account?
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.”
You are correct that we are vague about the threat model in this case. But please keep in mind that encrypting local data at rest defends against a whole category of "compromise" (i.e., the data stored long term on the local disk being captured) then the case of a malicious process running on the user's machine while the user is actively using 1Password.
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.
> 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".
I'm curious about whether you guys can address the distinction between "a malicious process with user privileges is running on the users machine" and "a malicious process with some other user's privileges is running on the machine.". That is, is there a threat that your TCP server could be impersonated, and what could happen in this scenario. It's easy to dismiss a scenario where you already have pwnd the 1password user, or worse, root, but TCP listeners aren't scoped to a user, they are scoped to a (potentially multi-user) machine.
No, it is not exploitable.
Yeah, 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.
In 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.
But could it leak something - lets say antivirus or firewall with heuristics picks up the traffic and sends it for analysis?
Don't install antivirus software on OS X. Who knows what crazy shit it might do to your system?
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.
Unfortunately, there is no way for browser extensions to create Unix sockets,
Also, code signing would prevent anyone from modifying the binaries to change the IP address.
But even if they could, UNIX domain sockets aren't immune to attacks. That sort of the problem with "First, assume your machine has been pwn'd".
Yes; if we assume the machine has been pwned, then whatever we can still trust is anywhere else but in that machine. At best we can come up with ways to securely smuggle bits through the pwned machine between two trusted endpoints; but we cannot manipulate any secrets on that machine.
(Trusted computing relies on some tamper-resistant core of the machine not being pwned when the rest of it is pwned.)
Indeed, it would be particularly amazing if a browser extension did that on Windows. :)
I explained in a previous comment the problem.
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...
You can't read loopback as a normal user. If you have root, you don't need to read unencrypted loopback traffic to get the passwords - just use a key logger.
Fair enough... or not!
First of all, when assessing security of a solution you have to define the perimeter of attack. You could imagine a privilege escalation that gives you access to the loopback interface but not enough to install a key-logger.
In other words, you are making an assumption that could be wrong!
Second, I could agree that perfect safety against every attack is impossible unless you assume your machine is switched off. But reasonable safety measure is achievable at low cost. Diffie and Hellman won the Turing price yesterday and their work is almost 40 years old...
> You could imagine a privilege escalation that gives you access to the loopback interface but not enough to install a key-logger.
That's a weird thing to say. If you manage to bypass file system access rules, there's any number of ways you can get access to the password manager.
I'm not convinced that any measure 1Password could take to make this harder would amount to more than mere obfuscation, with the cost of additional complexity (and attack surface).
That still means the password will be stored unencrypted in the browser's memory. AFAIK, this is no more secure than sending it unencrypted over the loopback interface; is there a scenario where one could snoop loopback, not not read browser memory?
yes, if the machine is reconfigured to allow loopback access for non-root users, they can sniff traffic but don't read arbitrary process memory. See discussion involving tptacek below, apparently Wireshark offers to make such changes, which might make it more common then one would expect initially (tons of devs have wireshark installed, and probably did that).
And where would the secret part of the TLS key be stored? As I've said before, encrypting with a key that is available to the attacker would merely be obfuscating. The only "value" of such obfuscation would be to conceal the security properties from the customer. It would make no difference to the attacker.
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.
The problem is that in this case both the server and the client are the same machine. And if you have root access to it then you have access to everything including the private keys of the server.
They could at least encrypt it across the socket.
How is the encryption key supposed to get into the Browser plugin?
Same 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.
In 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.
Yeah, you should stop the turtle sequence. Maybe don't make it so easy that a script kid could exploit it, though...
How do you exploit it without already having root or sufficient capabilities to attack 1Password in other ways?
At 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.
There is no modern OS on which you can sniff loopback without privileges.
Right, 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?
Nothing, but if you own the user's account, you also have their /Library directory to play with.
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.
Your system is misconfigured.
> $ 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'm on OS X 10.11.3:
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)
This is a fresh OS X install on a test machine :/
I don't know what to tell you. Normal users can't tcpdump loopback on OSX, or anywhere else.
> $ ls -l /dev/bpf* crw------- 1 root wheel 23, 0 Feb 29 07:59 /dev/bpf0 crw------- 1 root wheel 23, 1 Feb 29 07:59 /dev/bpf1 crw------- 1 root wheel 23, 2 Mar 2 11:11 /dev/bpf2 crw------- 1 root wheel 23, 3 Mar 2 10:07 /dev/bpf3 crw------- 1 root wheel 23, 4 Feb 29 08:11 /dev/bpf4Works for me too on OS X. sudo is not needed to run tcpdump for any interfaces.
$ ls -l /dev/bpf*
crw-rw---- 1 root access_bpf 23, 0 Mar 1 09:18 /dev/bpf0
Edit: Wireshark is installed
Did you install Wireshark? Did you let it reconfigure your system? Is your current user in the "access_bpf" group?
Later
Yes. Your system is misconfigured. Don't let Wireshark do that.
It looks like Wireshark will happily keep your system permanently misconfigured. To fix it, disable
/Library/LaunchDaemons/org.wireshark.ChmodBPF.plist
This actually seems like a much crummier thing than the 1Password non-thing.
Looks like you're logged in on a superuser account or have otherwise somehow disable some security settings.$ 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 also can't access loopback on 10.11.3, I get this exact error. And I'm running as an Administrator account.
Yeah, it's that they installed Wireshark, and gave it privileges to chown the loopback interfaces.
edit: Irony here is that Wireshark is doing something far more dangerous than 1password.
It's either a) change the group on the /dev/bpf entries and add your user to that group or b) run Wireshark as root.
b) would in general be a lot safer, in that you're elevating one process rather than lowering a privileged interface so that every process you run can sniff it.
Correct - Least Privilege says you do the absolute least you need to do in order to make things work, so that any errors are limited to that one part of the system.
What's been done here by Wireshark isn't least privilege, or secure. Its like the opposite of least privilege and security.
On Linux you can give an executable admin access to network devices with setcap which narrows it down further. Is the same possible on OS X?
Edit. Actually this is worse than running as root isn't it!
setcap is in principle better than setuid if your program is something like ping. Or in this case, wireshark.
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 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.
Someone 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.
I agree, but this makes it a helluva lot easier.
I don't agree that installing a key logger (of which there are hundreds out there) and stealing the encrypted password files is in any way harder than logging lo0 and waiting for passwords to slowly trickle in while they're being used.
They can do that anyways by sniffing the keyboard directly.
Sure, but this is a helluva lot easier.
Why on earth do I care? They're both easy.
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
12 hours.
I'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.
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.
Maybe 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.
They 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.
That sounds like a "It rather involved being on the other side of this airtight hatchway" problem.
https://blogs.msdn.microsoft.com/oldnewthing/20060508-22/?p=...
I 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.
I don't get it. Half of these comments are "this is stupid and impossible to exploit", half are calling this irresponsible disclosure.
They are not related in any way. Responsible disclosure does not mean that what is being disclosed is a real threat or not.
I believe this is the same issue that AgileBits has been aware of for some time. https://blog.agilebits.com/2015/06/17/1password-inter-proces...
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.
I 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
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.
This is a complete non-issue.
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.
So what?
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.
What's wrong with that?
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
> 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.
I 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?
Your firewall vendor knowing all your passwords? Nothing. And that is the most benign entity that could listen on the interface.
On a quick look this seems to be the same as the vuln discussed in http://arxiv.org/abs/1505.06836.
1Password responded in a blog post here https://blog.agilebits.com/2015/06/17/1password-inter-proces...
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.
If this was an easy task to tackle, we wouldn't be paying a commercial entity to take care of it.
You'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.
No, 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.
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.
[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
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.
If someone is observing your loopback isn't it just as likely they're keylogging and have your 1Password master keyphrase?
This is stupid.
Seems bad!
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.
Wow, the communication should be encrypted.
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.
Sending in plaintext is sloppy. You can have any protocol over loopback.
And 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.
Except 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.