Closed Bug 162409 Opened 19 years ago Closed 19 years ago
Can trick layout history into filling <input type=file> with text from <input type=text> using key collision
Layout history uses keys that look like this to refill forms in session history: Tagname>InputName>InputType>FormName>IndexInForm InputName and FormName can contain the > character, so it is possible to trick layout history into filling the contents of a text field into a file-upload field. This allows an attacker to upload a file if he knows its filename.
I'm working on a better demo.
Thanks to jesus_X and grok for writing the server side of this demo.
Attachment #95035 - Attachment is obsolete: true
This fixes the problem by putting all developer-controlled elements *after* non-developer-controlled elements like type in the key. Because the key is used only to match, if the first part (containing the type) does not match the entire key cannot match. And since none of the things inserted can be controlled directly by the developer, there is no chance of messing up that crucial part. This has been tested against http://www.johnkeiser.com/cgi-bin/mozform.pl (to ensure no regressions), Bugzilla bug entry and attachment pages, and the enclosed testcase.
Universal diff of previous patch.
Attachment #95073 - Attachment is obsolete: true
sicking, bz, reviews?
Comment on attachment 95074 [details] [diff] [review] Patch -u sr=bzbarsky
Comment on attachment 95074 [details] [diff] [review] Patch -u r=sicking
Attachment #95074 - Flags: superreview+ → review+
It might be worth adding some comment to make sure that noone changes this again. IE something about that author-data should be last so that it can't tamper with the type.
I actually considered that but figured people watching the checkin would notice; it would be nice to make this checkin seem as benign as humanly possible given the horrifying scope of the exploit.
Marking as ADT2 RTM, until we can discuss the severity and discoverability of this one with jesse and mitch.
Fix checked in to trunk. Leaving open until we decide what else to do with it.
Comment on attachment 95074 [details] [diff] [review] Patch -u a=asa for 1.0.x (asa gave approval just now)
Checked in on 1.1 branch.
Tested on Linux with the following: 1. Netscape 7.0 PR1 2. Patch build based on 8/13 trunk build Using the testcase created in comment 14, clicked on the button 'Make me upload /etc/passwd'. Results: In Netscape 7.0PR1 contents of file were returned. With patch build, contents of file were NOT returned.
jkeiser: Did we not check this into the 1.0 branch? Ia sk because there is no "fixed1.0.1" marking in the keywords, nor did I see a comment saying this was checked into the 1.0 branch, after Scott provided ADT approval. Pls advise ...
According to bonsai, this was checked in last night, so marking fixed1.0.1
Yes, sorry, things got hectic last night. It should be in this morning's builds. This is all the builds I am concerned with, resolving fixed. We need to notify the embedders we know about so that they can pick up this fix.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
bsharma: bindu, pls verify this as fixed on the 1.0 branch and the trunk.
Verified on 2002-08-14-trunk build on Win 2000. Loaded test cases in comment #1, #2, #3. All of them give either error or exception in the JS console.
Status: RESOLVED → VERIFIED
Verified on 2002-08-15-branch build on Win 2000. Loaded comment #1, #2 and #3 and all of them gave the appropriate error messages.
You need to log in before you can comment on or make changes to this bug.