In The XARA Vulnerabilities in MacOS X and iOS[1], I wondered why the original article[2] said that AgileBits, the maker of 1Password, also considered the issue difficult to address. After reading AgileBits’ explanation[3], I understood. Of course—that makes sense. I also think the paper’s authors’ wording, presumably intended to promote their achievement, is somewhat misleading.

The 1Password vulnerability identified by the paper’s authors was the possibility that malware could intercept communications from the 1Password browser extension to 1Password mini. 1Password mini is supposed to open a WebSocket on port 6263 and listen there, but if malware takes control of that port before 1Password mini does, it can steal passwords and other information sent by the 1Password browser extension. Put differently, it can only steal passwords that the user enters and then decides to save as new passwords in 1Password. It does not expose passwords already stored in 1Password.

In response, I wrote in The XARA Vulnerabilities in MacOS X and iOS[1], “I would have the 1Password application generate a key pair during installation, give the public key to the browser extension, and encrypt all communication from the browser extension to port 6263 with that public key.” That is certainly true. From AgileBits’ perspective, however, that would not solve the problem.

Why not?

In a situation where such a malicious program can be installed, directly extracting passwords as they are entered into the browser would be easier and more reliable than intercepting WebSocket communications sent from the 1Password browser extension to 1Password mini. Of course. Extracting every password entered provides far broader coverage and greater reliability than hijacking the port used by 1Password mini.

[1] http://www.sakimura.org/2015/06/3100/4/

[2] https://sites.google.com/site/xaraflaws/

[3] https://blog.agilebits.com/2015/06/17/1password-inter-process-communication-discussion/

Related posts