5 ms·

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 a

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

tptacek 11y ago
No, it is not exploitable.
- ultramancool 11y ago
  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.
- venomsnake 11y ago
  But could it leak something - lets say antivirus or firewall with heuristics picks up the traffic and sends it for analysis?
  - tptacek 11y ago
    Don't install antivirus software on OS X. Who knows what crazy shit it might do to your system?
- mixedbit 11y ago
  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.
nbadg 11y ago
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.” [1] https://news.ycombinator.com/item?id=11212318 https://news.ycombinator.com/item?id=11212318
- jpgoldberg 11y ago
  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-1passwords-defenses-against-keystroke-loggers/ 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.

tptacek 11y ago

No, it is not exploitable.

ultramancool 11y ago
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.
venomsnake 11y ago
But could it leak something - lets say antivirus or firewall with heuristics picks up the traffic and sends it for analysis?
- tptacek 11y ago
  Don't install antivirus software on OS X. Who knows what crazy shit it might do to your system?
mixedbit 11y ago
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.

nbadg 11y ago

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.” [1] https://news.ycombinator.com/item?id=11212318 https://news.ycombinator.com/item?id=11212318

jpgoldberg 11y ago
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-1passwords-defenses-against-keystroke-loggers/ 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.