Data leak across multiple Chrome profiles [Fixed in BETA-16]

mikeyh

The 4.7.1.4 Beta Chrome extension has a really bad defect that updates fields across Chrome people leaking user data.

Steps to Reproduce

Open person 1 and go to a login page eg https://accounts.google.com/
Open person 2 and go to same login page
Open person 3 and go to same login page

In person 3 select a login from 1P Extension for https://accounts.google.com/.

Email address in all 3 people is updated to same value.

These are supposed to be separate browser contexts separating clients / projects / personal.

This happens even with fields not included in the saved form fields.

I've found the 1P extension updating a Google Docs title in a different person with a login email address from a different client because they share the same base domain of google.com and that tab happened to be focused in the other person window.

There is absolutely no way a Google Docs title input field in a different person window should have data-com.agilebits.onepassword.user-edited="yes"

<input class="docs-title-input" spellcheck="false" type="text" autocomplete="off" guidedhelpid="editor_title" aria-describedby="docs-parent-collections-container-outer" value="Untitled document" tabindex="0" aria-label="Rename" style="visibility: visible; width: 34px;" data-com.agilebits.onepassword.initial-value="Untitled document" data-com.agilebits.onepassword.user-edited="yes" dir="ltr" data-tooltip="Rename">

I've also seen this with other completely unrelated form fields in different web apps that happen to share a common base URL.

---

1Password Version: 7.0.BETA-11
Extension Version: 4.7.1.4
OS Version: macOS 10.12.6
Sync Type: Not Provided

mikeyh

Confirmed on a fresh install of

• macOS 10.13.4
• Google Chrome 66.0.3359.13
• 1Password Extension 4.7.1.4
• 1Password 7..BETA-11

littlebobbytables

Hi @mikeyh,

So I can report that we're aware, it is on the to-do list and I hope will be corrected sometime soon. It is a regression in terms of the correct behaviour in 1Password 6 and was the result of the large code shakeup that has taken place in the 1Password 7 betas. I will be quite happy once the proper behaviour returns for those users that make use of multiple Chrome profiles.

ref: apple-270

derekkgilbert

Excellent catch, Mikey.

mikeyh

I am extremely disappointed in AgileBits for not communicating this as a known critical issue to beta testers.

If this has been communicated in release notes then please point me to that information as I clearly missed it.

mikeyh

Also need to know if this is a 1Password 7 beta app or 1Password extension beta issue (or both) as I need to revert to an older version or stop using 1Password.

This is a critical security flaw that leaks personal data.

mikeyh

No reply and no notes in the 7.0.BETA-12 release so uninstalled.

AGAlumB

@mikeyh: I'm sorry, but we're generally not able to reply within 4 hours, as we do try to respond to everyone's messages in the order in which they are received. And, unfortunately, when you post multiple times, you're just pushing your comments back to the "newest" again. :(

But none of that changes what lil bobby mentioned to you a few short hours earlier: that we're aware of the issue and working on a fix. Thanks for your patience in the mean time. :blush:

mikeyh

@brenty given the amount of issues and the associated security risks you really need to warn any chrome users using multiple profiles to not use 1P7 open and fill in any way.

1P7 open and fill is a critical security risk for anyone using multiple profiles in chrome that will open tabs in every profile and change random fields in web pages leaking data everywhere.

This should be in a known issues section of your release notes.

AGAlumB

Traditionally release notes include information on fixes made in that update, but I'll pass on your suggestion.

Can you tell me more about what personal data is being "leaked" in your case? I agree that there's a bug here that needs to be fixed, but I'm not seeing that borne out in your example.

mikeyh

@brenty updating the title of an unrelated google doc and other random web fields in every profile with 1Password fields is leaking data.

AGAlumB

Thank you for clarifying. But what I'm asking is what exactly was "leaked"? Did a password get filled into the title? I'm not seeing that here, so I wanted to make sure I wasn't missing something. Thanks!

mikeyh

Username / email address and I expect passwords as well which is why I stopped using.

eg logging into Google Apps in one profile pasted the email address into google docs titles of other clients in different profiles who should not be aware of each other.

I'll setup another VM to check passwords.

AGAlumB

Gotcha. I guess it depends on what you're filling. I agree that's unacceptable. We'll get it fixed.

mikeyh

@brenty passwords will be pasted into any input field with type="password" across all profiles with a common base domain.

Some weird logic here:

• looks like username will be pasted into first input field on page if no username field found or type="password" found in page
• username will be pasted into the input field prior to any found type="password" input field if no username field found
• password doesn't seem to care what the password input field name is in web form details and always looks for type="password"

Open and fill will open every chrome profile with a new tab and paste into fields of existing open chrome tabs with a common base domain.

Example One

This will always paste username into #status input field.

<!DOCTYPE html> <html> <head> </head> <body> <div> <input id="status" name="status" /> </div> <div> <input id="test" name="test" /> </div> <div> <input id="hint" name="hint" /> </div> <div> <input id="something" name="something" type="text" /> </div> <div> <input id="password" name="password" type="hidden" /> </div> </body> </html>

Example Two

This will always paste username into #hint and password into #something ignoring web form details of username and password.

<!DOCTYPE html> <html> <head> </head> <body> <div> <input id="status" name="status" /> </div> <div> <input id="test" name="test" /> </div> <div> <input id="hint" name="hint" /> </div> <div> <input id="something" name="something" type="password" /> </div> <div> <input id="password" name="password" type="hidden" /> </div> </body> </html>

Code block formatting of HTML does not work well here.

Ben

Code block formatting of HTML does not work well here.

Yep; sorry about that. I tried playing around with it to get it to display more nicely, but no dice.

Open and fill will open every chrome profile with a new tab and paste into fields of existing open chrome tabs with a common base domain.

I spoke with development about this yesterday and their response was that as soon as we hung up the call this is what they were working on, so fingers crossed it won’t be an issue in the next beta.

Ben

mikeyh

@ben thanks.

My original title was renamed from Very Bad Defect to just Defect and I probably should have called it Critical Security Defect.

I'm normally more careful with beta upgrades on production systems.

Looking through the blog posts, release notes and these discussions I made some incorrect assumptions about the stability of the 1P7 betas.

Currently working on GDPR updates and the last thing I needed was data leaking between clients.

Ben

I'm normally more careful with beta upgrades on production systems.

Yep, and I think that is prudent, but on the other hand I’m kinda glad that you did because it sounds like you’re running a fairly uncommon setup (at least not one that many of our beta testers would be testing in) and we may not have been able to find and fix this so quickly without your assistance.

My original title was renamed from Very Bad Defect to just Defect and I probably should have called it Critical Security Defect.

I wasn’t the one who changed that, but I suspect it was done prior to us knowing the full scope here. I’ll see if we can re-work that to make the issue here more clear.

Looking through the blog posts, release notes and these discussions I made some incorrect assumptions about the stability of the 1P7 betas.

I certainly don’t want to shrug this off as “well, it is a beta.” We do want folks to participate in the beta as that is the only way we find some of these bugs.

Ben

Ben

Just an update we do have the code written to fix this and as such there is a good chance it’ll be fixed in the next beta. I’ve updated the title to reflect that.

Ben

mikeyh

Using multiple chrome profiles is often a recommended setup to separate:

• personal vs work
• day to day operational vs accounts with elevated privileges
• internal vs external
• clients
• etc

Highly recommended for legal work and anything that needs basic compartmentalisation.

The extreme is separate VMs or even separate devices.

Ben

I understand the use case, it just hasn’t become very common practice yet. I see many more cases of separate user accounts to separate those things vs multiple profiles in a browser within the same user account.

Ben

AGAlumB

@mikeyh: This should be fixed in BETA-16, released probably after Ben was asleep for the night. Please give it a try and let us know if you confirm that this resolves the issue with your setup as well.

mikeyh

BETA-16 / BETA-18 seems to fix posting across profiles.

It does not fix the broken weird logic for locating the username and password field.

Open a google doc then try an open and fill with a login for a Google account.

It will still paste the username into the Google Docs title.

AGAlumB

BETA-16 / BETA-18 seems to fix posting across profiles.

@mikeyh: Thanks for confirming! Glad to hear all is well in that regard. :)

It does not fix the broken weird logic for locating the username and password field. Open a google doc then try an open and fill with a login for a Google account. It will still paste the username into the Google Docs title.

If I understand you correctly, that is to be expected. Correct me if I'm wrong, but you're saying you told 1Password to fill there. So it's just following your directive. Definitely helps that it's not filling on other pages though! Jamie was discussing this elsewhere recently, so you may want to check out his comments for more details, but please let me know if I've misunderstood anything.

mikeyh

@brenty how is posting a username into the first input text field on a page that does not even match the name of any web form fields supposed to be expected behaviour?

See my previous posts for example html pages.

Some weird logic here:

• looks like username will be pasted into first input field on page if no username field found or type="password" found in page
• username will be pasted into the input field prior to any found type="password" input field if no username field found
• password doesn't seem to care what the password input field name is in web form details and always looks for type="password"

Open and fill will still paste the username into the first text input field in the focused tab with a common base domain even if there are no matching username / passwords fields in the page.

This is a easy to do by accident.

AGAlumB

how is posting a username into the first input text field on a page that does not even match the name of any web form fields supposed to be expected behaviour?

@mikeyh:

Correct me if I'm wrong, but you're saying you told 1Password to fill there. So it's just following your directive.

Am I missing something?

Open and fill will still paste the username into the first text input field in the focused tab with a common base domain even if there are no matching username / passwords fields in the page. This is a easy to do by accident.

How so? Can you give me a concrete example? It sounds to me like you're telling 1Password to fill in a weird context and it's doing its best to accommodate you. Please clarify.

mikeyh

@brenty Seriously?

Posting your username into the first text input field on a page is a defect.

That's not even fuzzy logic.

Web form details specify what fields should be completed.

If you can't find the input fields specified in web form details the correct behaviour should be DO NOTHING then display something like a temporary floating message explaining why.

If you plan to keep that kind of weird matching then we need an opt out for higher security logins and accounts.

eg explicitly use the specified web form details / websites OR do nothing,

ie disable any fuzzy logic / guessing of web form fields and domains.

AGAlumB

Seriously?

@mikeyh: Yes, seriously.

Posting your username into the first text input field on a page is a defect.

Perhaps, but 1Password is designed to fill login forms. If you're telling it to fill on a page that has no login form, what's it supposed to do, say "no"?

That's not even fuzzy logic. Web form details specify what fields should be completed.

Right. But when the fields don't match, it falls back on other strategies. Otherwise any time you tried to fill an actual login on an actual login page at all different than where you'd originally saved it, 1Password would fail you utterly and completely every time, because the web form details didn't match perfectly.

If you can't find the input fields specified in web form details the correct behaviour should be DO NOTHING then display something like a temporary floating message explaining why.

You may think so, but you will find that there are a lot of other 1Password users out there who would not be happy if we did things your way.

If you plan to keep that kind of weird matching then we need an opt out for higher security logins and accounts. eg explicitly use the specified web form details / websites OR do nothing, ie disable any fuzzy logic / guessing of web form fields and domains.

It's an interesting idea, but it sounds likes bit contrived. Again, you're telling 1Password to fill on that page, aren't you? This discussion is ostensibly about a problem with 1Password filling on a page other than where you told it to. I think that makes perfect sense. But asserting that 1Password should also not fill on a page where you explicitly told it to seems a bit absurd.

It seems like there's a very simple solution to the problem you say you're having now, which doesn't involve breaking 1Password for a large number of users: if you don't want 1Password to fill on that page, don't tell it to.

thightower

@Ben

some code enclosed in 3 back ticks and closed with 3 back ticks. 
line 1 is 3 back ticks
line 2 ~ whatever is the code
last line is 3 back ticks

See if this code block formatting works for you. Seems to be the same thing that works in 1Password 7 for code formatting. I have been using it bunches to save some rather important scripts in notes.

My example pulled from a snippet on the web from @ http://littlesnippets.net

or compete apple script

set myPath to ((path to home folder) as text) & "Geektool:"
set artworkItunes to POSIX path of myPath & "iTunes.png"
set defaultPic to POSIX path of myPath & "default.png"

if running of application "iTunes" then
    tell application "iTunes"
        set artData to data of artwork 1 of current track
        set fileRef to (open for access artworkItunes with write permission)
        try
            write artData to fileRef starting at 0
            close access fileRef
        on error errorMsg
            try
                close access fileRef
            end try
            error errorMsg
        end try
    end tell
else
    tell application "Image Events"
        set defaultData to open defaultPic
        save defaultData as PNG in artworkItunes with replace
        close defaultData
    end tell
end if

mikeyh

@brenty I'm at a complete loss as to why you think posting username into the first random text input field in a web page is acceptable behaviour for a security product.

That is not a good user experience in any way.

Ben

@thightower

Nice! Thanks for sharing. :)

Ben