Closed
Bug 91316
Opened 23 years ago
Closed 23 years ago
Remote DoS by opening tty
Categories
(Core :: Security, defect)
Tracking
()
People
(Reporter: jwbaker, Assigned: security-bugs)
References
Details
Attachments
(2 files)
89 bytes,
text/html
|
Details | |
773 bytes,
patch
|
Details | Diff | Splinter Review |
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).
Comment 1•23 years ago
|
||
> 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?
Reporter | ||
Comment 2•23 years ago
|
||
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.
Comment 3•23 years ago
|
||
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).
Comment 4•23 years ago
|
||
Comment 6•23 years ago
|
||
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.
Comment 7•23 years ago
|
||
Reporter | ||
Comment 9•23 years ago
|
||
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.
Updated•23 years ago
|
Comment 10•23 years ago
|
||
> 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)
Assignee | ||
Comment 11•23 years ago
|
||
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
Comment 12•23 years ago
|
||
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
Assignee | ||
Comment 13•23 years ago
|
||
Boris, Sorry, no insult intended. Jesse is trying to resolve the regressions.
Comment 14•23 years ago
|
||
Mitch, no insult taken. If there's anything I can do to help (testing, whatever) let me know.
Comment 15•23 years ago
|
||
*** Bug 91657 has been marked as a duplicate of this bug. ***
Comment 16•23 years ago
|
||
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>.
Reporter | ||
Comment 17•23 years ago
|
||
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:///.
Comment 18•23 years ago
|
||
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.
Comment 19•23 years ago
|
||
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.
Comment 20•23 years ago
|
||
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.
Description
•