1520280 - FormHistory:AutoCompleteSearchResults loads shared-origin data into the content process

Status: NEW

(Toolkit :: Form Manager, defect, P3)

Description

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

My reading of the FormHistory:AutoCompleteSearchAsync / FormHistory:AutoCompleteSearchResults pair of Message Manager messages is that a content process sends a query to the parent asking for autocomplete results for a given field with a variety of limiting values. The parent returns results.

At no point does origin factor into the situation (which makes sense from one point of view; since you expect (.e.g) an email field to give you the same autocomplete suggestions regardless of the origin you are on.)

This does result in two types of data leaks:

1. A content process can trick a user into loading sensitive data into memory by creating a form text field with a particular fieldname (e.g. one from a target website) and getting them to interact with it. This will load the data into memory where it could be stolen from a Spectre-like attack.

2. A compromised content process can almost certainly enumerate the entire moz_formhistory database (and if not; a large majority of it) exposing a lot of personal data.

Comment 1

[Matthew N. [:MattN]]

(In reply to Tom Ritter [:tjr] from comment #0)

My reading of the FormHistory:AutoCompleteSearchAsync / FormHistory:AutoCompleteSearchResults pair of Message Manager messages is that a content process sends a query to the parent asking for autocomplete results for a given field with a variety of limiting values. The parent returns results.

IIRC the results then get sent to the parent process for display :( Did you see that happening?

At no point does origin factor into the situation (which makes sense from one point of view; since you expect (.e.g) an email field to give you the same autocomplete suggestions regardless of the origin you are on.)

That's right, the cross-origin behaviour is intentional.

This does result in two types of data leaks:

1. A content process can trick a user into loading sensitive data into memory by creating a form text field with a particular fieldname (e.g. one from a target website) and getting them to interact with it. This will load the data into memory where it could be stolen from a Spectre-like attack.

If there is user interaction required and a visible autocomplete popup I guess this is slightly less of a concern.

2. A compromised content process can almost certainly enumerate the entire moz_formhistory database (and if not; a large majority of it) exposing a lot of personal data.

The main issue is that our autocomplete widget wasn't properly architected for e10s, it was just patched to be functional.

If my memory is correct about the bouncing back and forth between content and chrome then the solution is to never send the data to the content process since it gets (correctly) displayed in the parent process anyways.

Comment 2

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

I see messages like this going to the parent:

 FormHistory:AutoCompleteSearchAsync
 ({
   id: 13,
   searchString: "t",
   params: {
     agedWeight: 2,
     bucketSize: 1,
     expiryDate: 1532538299829000,
     fieldname: "fname",
     maxTimeGroupings: 25,
     timeGroupingSize: 604800000000,
     prefixWeight: 5,
     boundaryWeight: 25
   }
 })

And messages like this coming to the child:

 FormHistory:AutoCompleteSearchResults
 ({
   id: 13,
   results: [{
     text: "Tom",
     guid: "vuGuVrO200+SKPSC",
     textLowerCase: "tom",
     frecency: 50,
     totalScore: 50
   }]
 })

I don't see 'vuGuVrO200+SKPSC' appear anywhere else in my logs; or any other relevant messages containing 'Form' in the topic.

Comment 3

[Chris Peterson [:cpeterson]]

Sending to Fission triage. Privacy/Security team doesn't think this bug needs to block Fission MVP, but they wanted the Fission to confirm (since it's been two years since this bug was originally tagged as Fission Future).

Comment 4

[Chris Peterson [:cpeterson]]

Fission Future

Nika says this bug doesn't need to block Fission MVP. This behavior already exists with e10s.

Comment 5

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

To follow up on this - I do see autocomplete entries being sent to the child even if the user does not actively select them from the dropdown.

Comment 6

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

We discussed this and consider it a blocker for disabling Spectre mitigations.

Because the entries are rendered in the parent, we should conceptually, be able to refactor (or fix, this might be a bug) this so entries are not sent to the child prior to a user actively selecting them.

Comment 7

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

I performed some more testing on this to confirm the above.

If the user merely visits a page, but does not interact with it at all, no autocomplete information is set to it, as expected.

If the user visits a page and then causes the autocomplete dropdown to open - autocomplete information will be sent, even before the user mouses over the choice or selects it. This is a bit of a leak; as the user hasn't actively chosen that data but it only occurs upon user interaction.

I can't get the autocomplete dropdown to open without user interaction via JS event trickery - it might be possible but it shouldn't be possible and if there's a bug, I haven't figured it out. I'm sure it could be done via clickjacking (no framing of a trusted site required; just stealing a user's click) - but this is no different from the status quo today; since if you're doing clickjacking you could trick the user into filling the form field and stealing it directly instead of via Spectre.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 19 votes.
:tgiles, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.