
1Password sends your password in clear text across the loopback interface - nullrouted
https://medium.com/@rosshosman/1password-sends-your-password-across-the-loopback-interface-in-clear-text-307cefca6389#.h9l20j6lv
======
jpgoldberg
[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...](https://blog.agilebits.com/2015/06/17/1password-inter-process-
communication-discussion/)

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.

~~~
nullrouted
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?

~~~
kentonv
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).

~~~
nullrouted
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.

~~~
kentonv
> 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!

~~~
tangled_zans
You make some very good points. Question is, is there any way to know if such
a malicious program is on your machine?

~~~
kentonv
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.

------
dcole2929
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
No, it is not exploitable.

~~~
venomsnake
But could it leak something - lets say antivirus or firewall with heuristics
picks up the traffic and sends it for analysis?

~~~
tptacek
Don't install antivirus software on OS X. Who knows what crazy shit it might
do to your system?

------
jish
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?

~~~
LukaAl
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...

~~~
pfg
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.

~~~
LukaAl
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...

~~~
pfg
> 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).

------
s800
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.

~~~
tonywebster
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.

~~~
tptacek
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)

~~~
tonywebster
This is a fresh OS X install on a test machine :/

~~~
tshtf
Works 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

~~~
tptacek
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.

~~~
pvg
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.

------
rdl
[https://blog.agilebits.com/2015/06/17/1password-inter-
proces...](https://blog.agilebits.com/2015/06/17/1password-inter-process-
communication-discussion/)

------
JonathonW
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.

~~~
jlgaddis
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.

~~~
pfg
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.

~~~
jlgaddis
I agree, but this makes it a helluva lot easier.

~~~
pfg
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.

------
rolfvandekrol
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'?

~~~
watson
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

------
aidos
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.

~~~
jlgaddis
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.

[0]:
[https://news.ycombinator.com/item?id=11206955](https://news.ycombinator.com/item?id=11206955)

~~~
matthewmacleod
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.

~~~
jlgaddis
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.

------
4doorsaloon
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...](https://blog.agilebits.com/2015/06/17/1password-inter-process-
communication-discussion/)

------
jMyles
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?

------
uptown
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.

------
joev_
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](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
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.

------
fixermark
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.

~~~
msbarnett
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.

------
tedmiston
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.

------
tptacek
So what?

------
kazinator
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.

------
slavik81
What's wrong with that?

~~~
LukaAl
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

~~~
afreak
> 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.

------
ikeboy
On 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-
proces...](https://blog.agilebits.com/2015/06/17/1password-inter-process-
communication-discussion/)

------
revelation
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.

~~~
nikolay
If this was an easy task to tackle, we wouldn't be paying a commercial entity
to take care of it.

~~~
revelation
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.

~~~
nikolay
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.

------
hoechst
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).

------
detaro
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.

~~~
bwoodruff
[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

------
city41
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.

------
Negative1
If someone is observing your loopback isn't it just as likely they're
keylogging and have your 1Password master keyphrase?

------
jtth
This is stupid.

------
draw_down
Seems bad!

------
euroclydon
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.

------
marvel_boy
Wow, the communication should be encrypted.

------
venomsnake
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.

~~~
elbigbad
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.

~~~
venomsnake
Sending in plaintext is sloppy. You can have any protocol over loopback.

~~~
jpgoldberg
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.

~~~
julie78787
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.

