Status

()

defect
RESOLVED FIXED
13 years ago
13 years ago

People

(Reporter: moz_bug_r_a4, Assigned: dveditz)

Tracking

({fixed1.7.13})

1.7 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

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

13 years ago
Posted file testcase
(Assignee)

Comment 2

13 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)

Updated

13 years ago
Blocks: 333305
(Assignee)

Comment 3

13 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.
moz_bug: your suggested change was checked in as part of bug 333305. I guess we can mark this fixed now?
(Reporter)

Comment 5

13 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

13 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

13 years ago
I see the same behavior with the latest respins on Windows and Linux (4/10 ~5pm).
(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.
I think we can mark this fixed-aviary1.0.8, fixed1.7.13.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
OS: Windows XP → All
Hardware: PC → All
Resolution: --- → FIXED

Comment 10

13 years ago
Making verified-aviary1.0.8 based on testing of the latest respins.
(Assignee)

Updated

13 years ago
Group: security
You need to log in before you can comment on or make changes to this bug.