Closed Bug 134986 Opened 22 years ago Closed 19 years ago

Checking for remote image existence

Categories

(Core :: Security, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: security-bugs, Assigned: security-bugs)

References

()

Details

This is a minor information leak - a script can determine if a file with some
recognized image format exists at a given URL, either on the user's local drive
or another site the user has access to, such as inside a firewall. If a file
exists at that URL but it is not an image file, this script will not be able to
see it. Adding CheckLoadURI to images would fix the local case, however this
causes some nasty regressions in Composer and has been postponed indefinitely.

The problem is that onLoad handlers for images fire only if an image exists.
What's the composer problem, exactly?

/be
Adding CheckLoadURI for images broke the ability to add local images to a page
in Composer.
So can't composer hackers fix that lesser bug, rather than causing this greater
(for a browser, and taking into account composer's relative market share and
other factors like quality) bug to be futured?

/be
Even if you think the composer bug that would result from closing this
information leak quickly is the greater bug, it's still wrong to leave this bug
hanging, and not to involve any composer people.  Mitch, can you find someone
who could help -- maybe jfrancis?

/be
Bug 69070 is the bug for adding checkloaduri to images
It appears Composer needs to be provided the appropriate api's to clue security 
in.  I thought Jesse did that in his patch: http://bugzilla.mozilla.org/
attachment.cgi?id=46183&action=view in bug http://bugzilla.mozilla.org/
show_bug.cgi?id=69070.

In comment 23 of that bug he mentions the change:
editor/base/nsEditorShell.cpp
 Added a setAppType call to tell the docshell it's a composer.  (Similar to code
in mailnews/base/src/nsMsgWindow.cpp.)

Tell me what security cruft to put in composer and I'll put it there.  If no such 
cruft exists, that's a bug.
I talked to Mitch about this bug last week when I was in MV.  He didn't seem to
think this was a problem that needed to be addressed in the MachV timeframe.

My understanding is that the fix is actually in nsImageFrame or somewhere
outside of mozilla/editor.  I have agreed to help Mitch with testing any
proposed patches.

Mitch--is the most recent patch in bug 69070 the correct patch to tweak to
address this bug?
I wonder if this problem is related to bug 148199 (broken images don't 
redisplay). If image onload isn't fired, that would explain bug 148199, which
actually *is* very important to fix for MachV
I think the risk of this fix outweighs the gain, so let's put this off for now.
The information leak caused by this bug is not very serious, right?
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.2alpha
Target Milestone: mozilla1.2alpha → mozilla1.3alpha
If the risk isn't very serious, then why don't we open the bug?
It seems pretty clear that there is a Composer bug that should be fixed so that
we can do the right thing and CheckLoadURI for images. This should be done
sooner rather than later.
Whiteboard: [sg:mustfix]
Group: security?
The intranet problem can also be fixed by implementing security zones, bug 165531.
I'm beginning to think CheckLoadURI for images is the wrong approach - it only
fixes the local drive case, not the intranet case, and I'm trying to move away
from CheckLoadURI where possible since it impedes some legitimate uses.

One way to fix this problem would be to lie about nonexistent images. According
to the Rhino Book, the Image.complete property should be set to true on error,
but it is not. I have filed bug 190561 on that. The other part is trickier - we
would have to stop throwing onError events and always throw onLoad instead,
which would violate the spec, I'm sure.

As this is a minor security issue, I have no strong feelings either way - either
lie to the DOM that all image loads are successful, or wontfix this bug and
maybe work on a Security Zones-type system instead as Heikki suggested. What say
you?
Target Milestone: mozilla1.3alpha → mozilla1.4alpha
Depends on: 69070
Not firing onError events is not exactly acceptable -- people do rely on those
for real error handling....
Blocks: 7266
Clearing milestone
Target Milestone: mozilla1.4alpha → ---
Whiteboard: [sg:mustfix] → [sg:fix]
We've plugged the local file hole (bug 69070), for remote web images there are
just too many ways to detect them.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → WONTFIX
Whiteboard: [sg:fix]
You need to log in before you can comment on or make changes to this bug.