61–70 of 147 posts
Earlier quoted context omitted.
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?
What's wrong with that?
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 do…
Every app that runs on your systems with enough privileges can dump the memory and extract information via that.
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.
I don't get it. Half of these comments are "this is stupid and impossible to exploit", half are calling this irresponsible disclosure.
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 orde…
No, it is not exploitable.
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.
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 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.
[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…
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 act…
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?
[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…
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 act…
[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…
Earlier quoted context omitted.
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)
This is a fresh OS X install on a test machine :/
$ ls -l /dev/bpf*
crw-rw---- 1 root access_bpf 23, 0 Mar 1 09:18 /dev/bpf0
Edit: Wireshark is installed