Autocomplete stuffing attacks

NEW
Unassigned

Status

()

Toolkit
Form Manager
7 years ago
2 years ago

People

(Reporter: dveditz, Unassigned)

Tracking

({sec-low})

unspecified
sec-low
Points:
---

Firefox Tracking Flags

(blocking2.0 -, status2.0 wanted, blocking1.9.2 needed, status1.9.2 wanted, blocking1.9.1 needed, status1.9.1 wanted)

Details

(Whiteboard: [sg:low])

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
Created attachment 457467 [details]
"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.
(Reporter)

Comment 1

7 years ago
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.
(Reporter)

Comment 2

7 years ago
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.
blocking1.9.1: --- → ?
blocking1.9.2: --- → ?
status2.0: --- → wanted
(Reporter)

Updated

7 years ago
blocking1.9.1: ? → needed
blocking1.9.2: ? → needed
Comment hidden (obsolete)

Comment 4

7 years ago
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

Updated

7 years ago
Group: core-security
Keywords: sec-low
This has been fixed?
You need to log in before you can comment on or make changes to this bug.