Last Comment Bug 578879 - Autocomplete stuffing attacks
: Autocomplete stuffing attacks
Status: NEW
[sg:low]
: sec-low
Product: Toolkit
Classification: Components
Component: Form Manager (show other bugs)
: unspecified
: All All
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-14 18:31 PDT by Daniel Veditz [:dveditz]
Modified: 2015-03-19 08:22 PDT (History)
11 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-
wanted
needed
wanted
needed
wanted


Attachments
"superfill" (824 bytes, text/html)
2010-07-14 18:31 PDT, Daniel Veditz [:dveditz]
no flags Details

Description Daniel Veditz [:dveditz] 2010-07-14 18:31:37 PDT
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.
Comment 1 Daniel Veditz [:dveditz] 2010-07-14 18:37:40 PDT
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] 2010-07-14 23:17:29 PDT
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] 2010-07-26 11:15:20 PDT Comment hidden (obsolete)
Comment 4 Giorgio Maone [:mao] 2010-07-31 00:54:40 PDT
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 2013-12-26 15:25:58 PST
This has been fixed?

Note You need to log in before you can comment on or make changes to this bug.