Closed Bug 206459 Opened 21 years ago Closed 20 years ago

Attempt to load image from local floppy drive

Categories

(Core :: Security, defect)

Product:
Core
Component:
Security
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 69070

People

(Reporter: smontagu, Assigned: security-bugs)

References

(
URL
)

Details

http://www.nps.gov/muwo/home.htm contains an image reference to
"file:///A|/images/pix-invs.gif". When loading the page Mozilla attempts to
retrieve the image and if the A: drive is empty brings up a dialog to say so,
which has to be dismissed to continue loading.

I know there is already bug 69070, duped to bug 7266, on the general issue of
image references to local files, but when the local file is on a removable disk
it is much worse from a UE point of view. There is a potential DOS attack here,
and disallowing it as a special case won't have the unwanted side effects for
Composer that I understand are blocking the general case.

IE attempts to access the floppy (the light goes on and I hear the drive motor)
and then continues to load the page without reporting an error.

Opera seems to ignore the <img> completely.
I agree, we should not prompt the user in this case. The fix for that would
probably be in necko, or the image code.
Status: NEW → ASSIGNED
IMHO Bug 153377 could be resolved as dupe of this. But please change the summary
to include all removable drives and the no disk popup/dialog. See Bug 153377
comment 19.
As far as I know, on Windows, the OS is what puts up that silly dialog.  If we
try to access the disk at all, we can't stop it coming up.  So this is just a
dup of bug 69070, imo.
Blocks: 153377
Depends on: 69070
Well, as I said in comment 0, IE seems to manage it somehow ;-)
*** Bug 153377 has been marked as a duplicate of this bug. ***
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/getvolumeinformation.asp

Remarks

If you are attempting to obtain information about a floppy drive that does not
have a floppy disk or a CD-ROM drive that does not have a compact disc, the
system displays a message box asking the user to insert a floppy disk or a
compact disc, respectively. To prevent the system from displaying this message
box, call the SetErrorMode function with SEM_FAILCRITICALERRORS.
The reference timeless cited in comment 6 is
the right solution.
a few things in no particular order:

1. i'd like to protest the resolution of a perfectly good bug which had a stack
trace against a new and utterly useless bug which had nothing.
2. SetErrorMode
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/base/seterrormode.asp>
is per application, not thread. so while we could use the patch I'm about to
post, it will eventually break.

"Because the error mode is set for the entire process, you must ensure that
multi-threaded applications do not set different error-mode flags. Doing so can
lead to inconsistent error handling."

3. The bug that was duped was about chrome code. Whereas the summary of this bug
is clearly about remote content loading local images.

4. Ignoring the above, afaik all instances of the problem from Bug 153377
(FindFirstFile) seem to reside in a few places:
nspr
xpinstall
(a fork of xpinstall, because one xpinstall just wasn't enough)
printing (*cough*)
eudora import for windows (because writing portable code just isn't worth
anyone's effort)
nss
plugins

ok. that's a few more than i want to fix. but it could be worse. and perhaps i
can get a few of them to just go away.

anyway, i'm going to post a patch for nspr but i think the right fix is for
something, at some init time, to call SetErrorMode *once* before threads are
created and for no one else to ever call it again for the life of the app.

Anyway. I'm annoyed. This bug dies. People who care can go find the bugs I'm
actually going to use to post patches.

*** This bug has been marked as a duplicate of 69070 ***
No longer blocks: 153377
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
No longer depends on: 69070
Resolution: --- → DUPLICATE
Not a dupe of 69070 for reasons already adequately explained. I agree that bug
153377 shouldn't have been duped to this, but I don't see the point in
tit-for-tat duping.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Well, then at least post a stack trace.
I don't get how one of these is not the dupe of the other.
What's up with the removed dependencies?
BugsThisDependsOn 69070, OtherBugsDependingOnThis 153377
ostgote@gmx.net: this is an open source bug tracking system. you're expected to 
to read the bugs before you ask questions about them. these bugs are not 
dependent on eachother and therefore the dependencies have been removed.
*** Bug 264667 has been marked as a duplicate of this bug. ***
I had thought that bug 69070 would have fixed this, but no.

Stack trace:
_PR_MD_GETFILEINFO64(const char * 0x039f3308, PRFileInfo64 * 0x039f4cf0) line 784
PR_GetFileInfo64(const char * 0x039f3308, PRFileInfo64 * 0x039f4cf0) line 528 +
13 bytes
nsLocalFile::ResolveAndStat() line 521 + 17 bytes
nsLocalFile::GetLastModifiedTime(nsLocalFile * const 0x039f4cc0, __int64 *
0x0012ed0c) line 1432 + 8 bytes
imgCache::Get(nsIURI * 0x039f72c0, int * 0x0012efb4, imgRequest * * 0x0012f020,
nsICacheEntryDescriptor * * 0x0012efa8) line 270 + 36 bytes
imgLoader::LoadImage(imgLoader * const 0x00c0a7f0, nsIURI * 0x039f72c0, nsIURI *
0x03a23548, nsIURI * 0x03a23548, nsILoadGroup * 0x0384aff0, imgIDecoderObserver
* 0x039f7164, nsISupports * 0x039cd680, unsigned int 0x00000000, nsISupports *
0x00000000, imgIRequest * 0x00000000, imgIRequest * * 0x039f7168) line 300 + 50
bytes
nsContentUtils::LoadImage(nsIURI * 0x039f72c0, nsIDocument * 0x039cd680, nsIURI
* 0x03a23548, imgIDecoderObserver * 0x039f7164, int 0x00000000, imgIRequest * *
0x039f7168) line 1768 + 58 bytes
nsImageLoadingContent::ImageURIChanged(const nsACString & {...}) line 478 + 69 bytes
nsImageLoadingContent::ImageURIChanged(nsImageLoadingContent * const 0x039f7164,
const nsAString & {...}) line 411 + 21 bytes
nsHTMLImageElement::SetParent(nsIContent * 0x039f7d00) line 634
nsGenericElement::AppendChildTo(nsIContent * 0x039f7148, int 0x00000000, int
0x00000000) line 2600
SinkContext::AddLeaf(nsIHTMLContent * 0x039f7148) line 1565
SinkContext::AddLeaf(const nsIParserNode & {...}) line 1497
HTMLContentSink::AddLeaf(HTMLContentSink * const 0x0378b170, const nsIParserNode
& {...}) line 3125 + 18 bytes
CNavDTD::AddLeaf(const nsIParserNode * 0x03666080) line 3760 + 25 bytes
CNavDTD::HandleDefaultStartToken(CToken * 0x03a103f0, nsHTMLTag eHTMLTag_img,
nsCParserNode * 0x03666080) line 1432 + 12 bytes
CNavDTD::HandleStartToken(CToken * 0x03a103f0) line 1807 + 20 bytes
CNavDTD::HandleToken(CNavDTD * const 0x039c8fe0, CToken * 0x03a103f0, nsIParser
* 0x03a12b28) line 992 + 12 bytes
CNavDTD::BuildModel(CNavDTD * const 0x039c8fe0, nsIParser * 0x03a12b28,
nsITokenizer * 0x03937598, nsITokenObserver * 0x00000000, nsIContentSink *
0x0378b170) line 471 + 20 bytes
nsParser::BuildModel(nsParser * const 0x03a12b28) line 2027 + 34 bytes
nsParser::ResumeParse(int 0x00000001, int 0x00000000, int 0x00000001) line 1894
+ 12 bytes
nsParser::OnDataAvailable(nsParser * const 0x03a12b2c, nsIRequest * 0x0391df88,
nsISupports * 0x00000000, nsIInputStream * 0x03a4ce80, unsigned int 0x00000000,
unsigned int 0x00000066) line 2572 + 21 bytes
nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x039992f8,
nsIRequest * 0x0391df88, nsISupports * 0x00000000, nsIInputStream * 0x03a4ce80,
unsigned int 0x00000000, unsigned int 0x00000066) line 342 + 46 bytes
nsFileChannel::OnDataAvailable(nsFileChannel * const 0x0391df90, nsIRequest *
0x0321bce0, nsISupports * 0x00000000, nsIInputStream * 0x03a4ce80, unsigned int
0x00000000, unsigned int 0x00000066) line 556
nsInputStreamPump::OnStateTransfer() line 435 + 70 bytes
nsInputStreamPump::OnInputStreamReady(nsInputStreamPump * const 0x0321bce4,
nsIAsyncInputStream * 0x03a4ce80) line 338 + 11 bytes
nsInputStreamReadyEvent::EventHandler(PLEvent * 0x03564874) line 119
PL_HandleEvent(PLEvent * 0x03564874) line 692 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00c9bbd8) line 627 + 9 bytes
nsEventQueueImpl::ProcessPendingEvents(nsEventQueueImpl * const 0x00c9ebe8) line
394 + 12 bytes
nsWindow::DispatchPendingEvents() line 3721
nsWindow::ProcessMessage(unsigned int 0x00000101, unsigned int 0x00000074, long
0xc03f0001, long * 0x0012fc4c) line 3932
nsWindow::WindowProc(HWND__ * 0x01d20772, unsigned int 0x00000101, unsigned int
0x00000074, long 0xc03f0001) line 1355 + 27 bytes
USER32! 77d43a50()
USER32! 77d43b1f()
USER32! 77d43d79()
USER32! 77d43ddf()
nsAppStartup::Run(nsAppStartup * const 0x00c1fc90) line 221
main1(int 0x00000001, char * * 0x002a4448, nsISupports * 0x00b526c0) line 1321 +
32 bytes
main(int 0x00000001, char * * 0x002a4448) line 1799 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e8
Oops, my mistake, it is fixed.

*** This bug has been marked as a duplicate of 69070 ***
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.