Closed Bug 91316 Opened 23 years ago Closed 23 years ago

Remote DoS by opening tty

Categories

(Core :: Security, defect)

All
Linux
defect
Not set
critical

Tracking

()

VERIFIED DUPLICATE of bug 69070

People

(Reporter: jwbaker, Assigned: security-bugs)

References

Details

Attachments

(2 files)

The following HTML will cause Mozilla (and Netscape 4.77) to open /dev/tty0,
which will cause all keyboard input from /dev/tty0 to be eaten:

<img src="file:///dev/tty0">

I suggest that Mozilla should never attempt to open a file URI when the content
has been loaded via something other than file (http, https, ftp, etc).
> I suggest that Mozilla should never attempt to open a file URI when the content
> has been loaded via something other than file (http, https, ftp, etc).

We already do this... you can't load file:// uris from content unless the
content was loaded via file:// or chrome://

Do you have a testcase that shows that that's not the case?
http://atari.saturn5.com/~jwb/tty0.html

Eats the keyboard every time.  This is all over bugtraq.  I tested with 0.9.1
and latest nightly on Linux.
Okee.  Looks like we block _going_ to file:// urls from http:// urls.  But we
don't block image loads from file:// urls?

This seems very wrong.

Attaching testcase that's "improved" a bit (have to try /dev/pts/0 as well as
/dev/tty0).
Attached file evil testcase
*** Bug 91323 has been marked as a duplicate of this bug. ***
Argh!  The problem code is at
http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsImageFrame.cpp#1599

1604 #if 0
1605 nsCOMPtr<nsIScriptSecurityManager>
     securityManager(do_GetService(NS_SCRIPTSECURITYMANAGER_CONTRACTID));
1606 
1607 if (securityManager) {
1608   nsCOMPtr<nsIURI> baseURI;
1609   GetBaseURI(getter_AddRefs(baseURI));
1610 
1611   nsresult proceed = securityManager->CheckLoadURI(baseURI, aURI,
          nsIScriptSecurityManager::STANDARD);
1612 if (NS_FAILED(proceed))
1613 return PR_FALSE;
1614 }
1615 #endif

Why the is that in #if 0?  The checkin comment for the checkin that added that #if:

1.172 mstoltz%netscape.com
May 18 17:33 Re-checking-in my fix for 47905 , which was backed out last night
because of a bug in some other code that was checked in along with it. This
checkin was not causing the crasher and is unchanged. See earlier checkin
comment - in short, this adds same-origin to XMLHttpRequest and cleans up some
function calls in caps, removes some unnecessary parameters. r=vidur, sr=jst. 

removing the #if 0 fixes this bug.
Reviews?
Keywords: patch, review
There's a companion bug to this, that I might file separately.  In whatever
handles file input streams, the code should be checking to see whether the file
is a regualr file or not.  There isn't any reason to open device files, ever.
Keywords: patch, review
Keywords: patch, review
> There isn't any reason to open device files, ever.

What about audio devices?  Like when we want to play sound?

What about other non-browser Mozilla-based applications (I can see XMLTerm
wanting to open a tty, for example)

Boris,
  There's a reason why that security check is ifdef'd out - it causes some
as-yet-unresolved regressions. We're working on it. Please don't check it in yet.

*** This bug has been marked as a duplicate of 69070 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Mitch, I wouldn't check something like that in without a review from you....  I
hope you realize that.  :)

Verified duplicate.  I sorta suspected that something was up with that code...
shoulda checked for dups.
Status: RESOLVED → VERIFIED
Boris,
   Sorry, no insult intended. Jesse is trying to resolve the regressions.
Mitch, no insult taken.  If there's anything I can do to help (testing,
whatever) let me know.
*** Bug 91657 has been marked as a duplicate of this bug. ***
I must be missing something but why is this a mozilla bug? You can shoot
yourself in the foot equally well by doing "cat /dev/tty0" from an
xterm. It's an X issue.

Blocking special devices violates the Unix tradition that, if you have
the right permissions, you are allowed to read the file; whatever it
might be. Why is it wrong to read a fifo? I would be annoyed if I
couldn't read <file:///proc/self/maps>.
You must be joking tenthumbs!?  Do you really think that a page, retrieved via
http, should be allowed to arbitrarily instruct Mozilla to open and read from a
device?

This isn't meant to stop you from typing arbitrary file:/// URLs into the
location bar, or specifying them in HTML loaded via file:///.
Uhm.. Denial of service triggered by remote webpages because they have <img
src="file://dev/pts0"> or what have you.  The thing is, although you are free to
shoot yourself in the foot, the browser should not aid remote, unknown agents in
shooting you in the foot.  THAT is a security problem.
Actually ignoring a DoS remote vulnerability like this would violate the Unix
tradition in a big way. This must be fixed ASAP as security vulnerabilities
usually are in the Open Source world.
Of course I'm not saying arbitrary html should open local files. It
sould not be allowed to open any files at all without the user's
explicit consent. The example here just demonstrates that Unix files
sometimes have side effects.

However, I did get the impression here that reading special files was
inherently a bad idea and I think that's wrong.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: