dylang Reporter
	Description • 23 years ago

As pointed out on bugtraq, Mozilla doesn't check to see if a file is a device
node  before opening.  The stat(2) function (POSIX, and many others) provides a
method of determining this easily without subjecting the user to a potential
crash or other problem.

Windows has no such analog, so you won't be able to use it to fix the
file://con/con bug there.  Oh well :)

From the Bugtraq posting:
"
On Wed, 18 Jul 2001, Ishikawa wrote:

> The next is a showstopper.
> The problem URL that caused the hung of browser,
> at least, on my PC is the following.

>     file:///dev/pty0

However, the UNIX API has a very simple and *reliable* way around this:

        stat(2)

I hope Mozilla authors are listening and start stat'in file:/// urls.

There is no simple and reliable equivalent under 'doze.
"

	dylang Reporter
	Comment 1 • 23 years ago

From: "Jeffrey W. Baker" <jwbaker@acm.org>

On Wed, 18 Jul 2001, Ishikawa wrote:

> The next is a showstopper.
> The problem URL that caused the hung of browser,
> at least, on my PC is the following.
>
>     file:///dev/pty0
>
> This locked my netscape navigator solid.
> I had to kill it using kill command from another
> xterm window. X didn't get hung, etc..
> Since trying other devices may cause more severe problems
> I stopped testing here.

Using <img src="file:///dev/tty0"> on my Linux machine caused Netscape and
Mozilla both to eat all the keyboard input.  I had to use another machine
to kill it.  I expected Netscape to NOT open file URIs from within a page
fetched via !file (http, https, ftp, gopher, etc.).

-jwb

	dylang Reporter
	Comment 2 • 23 years ago

Tossing to networking, since they'd be the ones to talk to (oops) :)

	dylang Reporter
	Comment 3 • 23 years ago

Ok, I obviously suck at double checking the query page.  Marking dupe.

*** This bug has been marked as a duplicate of 91316 ***

	timeless
	Comment 4 • 23 years ago

.

	benc
	Comment 5 • 23 years ago

REOPEN: -> file
Even though "checkURI" has cut off using this as a denial of service, it sounds 
like we still need to do what is described here, b/c it is the "right" way of 
doing things.

In the future, I can expect that (given the number and temperature of the 
objections to the default behavior), that significant number of individuals will 
elect to turn off "checkURI" but will still not want their keyboard to disappear 
on a tricked out file: URL.

	Mitchell Stoltz (not reading bugmail)
	Comment 6 • 23 years ago

More to the point, it's possible that fixing this bug may allow us to safely
remove some calls to CheckLoadURI.

	Asa Dotzler [:asa]
	Comment 7 • 23 years ago

->reassign

	benc
	Comment 8 • 23 years ago

*** Bug 91402 has been marked as a duplicate of this bug. ***

	benc
	Comment 9 • 23 years ago

+testcase (I'll be sure to run this last...)

	benc
	Comment 10 • 23 years ago

Mitchell: you wanted me to remind you about fixing this, it is still untargeted 
(adding mozilla1.0 keyword)

	Doug Turner (:dougt)
	Comment 11 • 23 years ago

I do not think this is a bug that necko should fix.  If the application built
around necko wants to stop devices from being opened, they should restrict these
URLs.  I can easily imagine a application that wants to open a stream to a
device file.  

Maybe this should be file handling at the application level or WONTFIX all together.

	Mitchell Stoltz (not reading bugmail)
	Comment 12 • 23 years ago

Please don't mark this WONTFIX - I'd really like this to be fixed somewhere, if
not in Necko. Regardless of what some hypothetical application built around
Necko might want to do, our application should not try to open device files
because that's a very easy way for a malicious site to cause mischief.
Implementing this restriction will allow me to loosen up the CheckLoadURI policy
to some degree, and that will make a lot of people happy.

	Bill Law
	Comment 13 • 23 years ago

->mscott

The only place we might could plug this hole is in the uriloader, I suspect.

We'd also need to hack some stuff in nsWebBrowserPersist when doing "save link
as..." (and maybe some other places?

	[not reading bugmail]
	Comment 14 • 23 years ago

note:

bug 122523 bug removed a |stat()| call recently and then it caused bug 127408.

	Daniel Clemente
	Comment 15 • 22 years ago

Also, I tried to open the serial port COM2 on /dev/ttyS1 and noticed that
Mozilla started using the port and didn't stop even after completely quitting
Mozilla.

[root@localhost guest]# fuser -v /dev/ttyS1
                     USER        PID ACCESS COMMAND
/dev/ttyS1           guest      2240 f....  mozilla-bin
                     guest      2249 f....  mozilla-bin
        [.......]

I had to kill it; then the LED I had put on the serial port switched off again.

	Christian :Biesinger (don't email me, ping me on IRC)
	Comment 16 • 22 years ago

nsIFile's isSpecial method might be useful here
http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsIFile.idl#254

	Mike Shaver (:shaver -- probably not reading bugmail closely)
	Comment 17 • 19 years ago

Since remote content can't cause us to load file: URLs any more, the security
issue here is no longer relevant, and restricting file: further is neither
necessary nor wise.