Closed
Bug 333428
Opened 20 years ago
Closed 20 years ago
Fix for Bug 293527 can be circumvented
Categories
(Core :: Security, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: moz_bug_r_a4, Assigned: dveditz)
References
Details
(Keywords: fixed1.7.13)
Attachments
(1 file)
|
13.19 KB,
text/html
|
Details |
<img id="i" src="a.png">
i.src = "http://otherdomain/x.exe";
If the "Load Images for the originating web site only" option is enabled, |src|
property is changed to the new value, but imgIRequest object is not changed,
and |request && (request.imageStatus & request.STATUS_SIZE_AVAILABLE)|
condition is still true.
Thus, "Save Image As..." item appears on the context menu, and it works for the
new |src| value.
I've tested with gavin's patch v3 for Bug 333305. I think the following change
could fix this.
- if (this.onImage && (this.target instanceof nsIILC)) {
+ if (this.onImage && (this.target instanceof nsIILC) &&
+ !this.target.imageBlocked) {
| Reporter | ||
Comment 1•20 years ago
|
||
| Assignee | ||
Comment 2•20 years ago
|
||
maybe nsImageLoadingContent should null the current request when loading a new one is blocked (near here? http://lxr.mozilla.org/aviary101branch/source/content/base/src/nsImageLoadingContent.cpp#405)
At this point on the old branch I wouldn't want to worry about side effects of that elsewhere, I think your suggestion is safer for now.
| Assignee | ||
Comment 3•20 years ago
|
||
> If the "Load Images for the originating web site only" option is enabled,
Note that this is not required for this testcase nor this attack. Changing the src to a non-image such as the executable in the original bug 293527 is all you need to fool us.
Comment 4•20 years ago
|
||
moz_bug: your suggested change was checked in as part of bug 333305. I guess we can mark this fixed now?
| Reporter | ||
Comment 5•20 years ago
|
||
(In reply to comment #4)
> I guess we can mark this fixed now?
Probably yes. (Today I don't have enough time for more testing.)
(In reply to comment #3)
> > If the "Load Images for the originating web site only" option is enabled,
>
> Note that this is not required for this testcase nor this attack.
I cannot reproduce this when "Load Images for the originating web site only"
option is disabled.
When that option is disabled, a non-image file is not blocked, and <img>
element becomes broken image. Thus, "Save Image As..." item does not appear on
the context menu.
Comment 6•20 years ago
|
||
For what it's worth, I don't see the "Save Image As..." option in the context menu at all with the testcase, doesn't matter whether the "originating web site only" pref is set or not. I guess that means this is "fixed", eh?
Comment 7•20 years ago
|
||
I see the same behavior with the latest respins on Windows and Linux (4/10 ~5pm).
Comment 8•20 years ago
|
||
(In reply to comment #6)
> For what it's worth, I don't see the "Save Image As..." option in the context
> menu at all with the testcase, doesn't matter whether the "originating web
> site only" pref is set or not. I guess that means this is "fixed", eh?
Yeah, it should match 1.5.0.2 (and current trunk/1.8 branch) behavior. The fix was essentially to prevent "Save as" from appearing with the testcase.
Comment 9•20 years ago
|
||
I think we can mark this fixed-aviary1.0.8, fixed1.7.13.
Status: NEW → RESOLVED
Closed: 20 years ago
Keywords: fixed-aviary1.0.8,
fixed1.7.13
OS: Windows XP → All
Hardware: PC → All
Resolution: --- → FIXED
Comment 10•20 years ago
|
||
Making verified-aviary1.0.8 based on testing of the latest respins.
Keywords: fixed-aviary1.0.8 → verified-aviary1.0.8
| Assignee | ||
Updated•20 years ago
|
Group: security
You need to log in
before you can comment on or make changes to this bug.
Description
•