578879 - Autocomplete stuffing attacks

Status: RESOLVED FIXED

(Toolkit :: Form Manager, defect)

Description

[Daniel Veditz [:dveditz]]

Attachment: "superfill"

Jeremiah Grossman reported that while we fixed the data-stealing attacks against form-fill data, he can still stuff an arbitrary amount of data into it.

  "Mostly just really annoying right now. Possibly spoof things if you
  wanted frame someone for a crime in the case of a forensics investigation.
  Other than that, see any security implications? Wanted to check quickly
  before posting on the blog as something interesting. Don't think this
  issue is exclusive to Firefox."

An attacker could try to run someone out of disk space: looks like we truncate data at 200 chars, allow field names of up to 200 chars, and will store up to 100 fields per form, so that's ~40K (or ~80K? not sure if it's chars or bytes) per submit, and you could have a lot of submits going on a page. It'd take a while to make a dent in today's large drives, but it could still be bad. Easy to recover by clearing Form data if you notice the problem.

Another annoying attack might be to fill the form data with spam text ads that users will see every time they visit a form with a popular field name. Maybe Jesse can think of other devious attacks.

One aspect that is browser specific is that Toolkit's form manager saves just by field name, it's not limited by site. This is often a useful feature but makes attacking Firefox more useful because you don't have to compromise the domain you want the content to appear on. And in the forensics case, there's no record that the "how do I hide a body" search was from a random compromised site and not really entered on a search engine site.

Safari's form fill, in contrast, appears to be keyed by the site which makes some of these attacks harder to pull off. It also makes it easier to defend against the spamming attack because they could apply per-domain quotas, although you'd have to apply it to an eTLD+1 to be effective.

Comment 1

[Daniel Veditz [:dveditz]]

Our form manager already doesn't save data where the submitted value matches the initial value attribute. Can we extend that to exclude fields that have not had a non-synthetic event targeted at it? If the value in a field comes from JavaScript we might as well consider it a default value. Legit events would be key presses (of course) and paste. If we can't detect paste we could maybe consider a mouseclick as good enough, and accept that some stuffage could happen with a form disguised as a game. But at least that limits the damage to human speed which is a different scale than the current potential attack.

Comment 2

[Daniel Veditz [:dveditz]]

At a high level this will be mentioned in one of the BlackHat talks in a couple of weeks so we probably want to prepare a response.

Comment 3

[Dave Townsend [:mossop]]

Doesn't sound like this blocks but re-nom if I've misread the severity of this.

Comment 4

[Giorgio Maone [:ma1]]

I guess this can be opened, since it's detailed here: http://jeremiahgrossman.blogspot.com/2010/07/in-firefox-we-cant-read-auto-complete.html

Comment 5

[mandatoryregistration]

This has been fixed?

Comment 6

[Sergey Galich [:serg]]

Bug 1642570 and bug 1771806 addressed this kind of problem: form history can store only data entered by user.
Script injected or prefilled values are ignored now.