Where are you getting support for sftp: ? An external protocol handler shouldn't be able to work in this way and I don't see any code for it in our tree. Did you install something that added additional protocol handlers to Mozilla?
(In reply to comment #2) > Where are you getting support for sftp: ? An external protocol handler > shouldn't be able to work in this way and I don't see any code for it in our > tree. > > Did you install something that added additional protocol handlers to Mozilla? > haven't installed any additional protocol handlers. works at least on vanilla ubuntu and mandriva. suspect this support comes from gnome-vfs.
the rebranded kubuntu firefox 220.127.116.11 doesn't have sftp support. branded firefox from ftp.mozilla.org does have sftp support.
the kubuntu firefox has "--enable-gnome-vfs", gnome-vfs isn't installed on kubuntu and sftp still works on official builds.
linux cvs trunk doesn't recognize sftp if this matters with default debug build.
support of sftp protocol: ff 18.104.22.168 from m.o.: yes ff trunk from m.o.: no ff cvs debug trunk: no kubuntu 7.0.4 ff 22.214.171.124: no ubuntu 6.0.6 ff 126.96.36.199: yes
OK. I finally got a chance to look at this. We do support sftp via the gnome-vfs protocol handler by default. This can be overridden by setting the network.gnomevfs.supported-protocols preference. What's this set to in your various builds? You probably also need gnomevfs in --enable-extensions. Is it there in the various builds involved? Note that on trunk untrusted content can't do loads through gnome-vfs at all: see nsGnomeVFSProtocolHandler::GetProtocolFlags. So there's no point testing trunk, and the only odd data point is the kubuntu one... Frankly, I think that we should add smb and sftp to the list of DenyProtocol protocols on branches, and remove branch support for the pref that allows adding other protocols to the gnome-vfs handler. That way we get safe behavior on branches. Trunk is already safe. Sort of. All you really have to do is to get the user to copy/paste or drag/drop the link... Of course the other option is to disable this altogether until we can do it safely.
10 years ago
(In reply to comment #8) > So there's no point testing > trunk, and the only odd data point is the kubuntu one... > kubuntu doesn't have gnome/all the gtk stuff so it may be because of this. > All you really have to do is to > get the user to copy/paste or drag/drop the link... > this is not correct - the testcase works when opened via http as long as the user has valuable ~/.ssh/id_* blacklisting specific protocols doesn't work. what would you do when gnomevfs exposes something even more dangerous? why not just switch to trunk behavior?
actually trunk from m.o. loads sftp when pasted in location bar which may be nasty. so at least a strong warning like on macosx should be shown.
> All you really have to do is to > get the user to copy/paste or drag/drop the link... I was talking about trunk here. If the user does this with an sftp:// link, it'll get loaded. > blacklisting specific protocols doesn't work. Of course. That's why we white-list the protocols we allow gnome-vfs to handle. There's a preference for this white-list, with the default value being "smb" and "sftp" and nothing else. > why not just switch to trunk behavior? Trunk behavior depends on architecture changes which are not available on branch. We could switch to an approximation of trunk behavior, as described in comment 8. > actually trunk from m.o. loads sftp when pasted in location bar Precisely. Can the same issues come up with smb: ? If not, perhaps we should just disable sftp: through gnome-vfs and be done with it?
(In reply to comment #11) > Can the same issues come up with smb: ? If not, perhaps we should just disable > sftp: through gnome-vfs and be done with it? > will have to check smb - it broadcasts. in case it caches credentials it may be a problem. probably on windoze cached credentials also cause troubles: file:\\\\DABOX\voayeur\0wn.html referencing file:\\\\DABOX\chick\private\pics someone doing windoze may want to check.
this is strange about smb - it works: data:text/html;,<iframe src="smb:///" />
Odd. Depending on how you load that data: URI, it _might_ work if the data: is running as chrome. But in general it shouldn't, on some random web page...
btw, where does "sftp" come from? in firefox 2.0 from m.o. strings -a firefox204/firefox-bin | grep -i sftp nsFtpProtocolHandler gvim -R firefox204/firefox-bin :set ic /sftp only 1 match: nsFtpProtocolHandler
> btw, where does "sftp" come from? http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/extensions/gnomevfs/nsGnomeVFSProtocolHandler.cpp&rev=1.14#818 And branch equivalent.
aaa, it is in firefox204/components/libnkgnomevfs.so
restoring bz's nom...
another external protocol handlers are: man:bash on linux and x-man-page://bash on macosx ppc
What does that have to do with this bug?
(In reply to comment #22) > What does that have to do with this bug? > ooops, i wrote in the wrong bug. in Bug 381006 Comment #6 dveditz asked |Other than mailto: what external protocol handlers do you have that are making connections without asking you first?| so i thought dveditz was hunting for external protocols (i do) and pointed out man: is accessible. don't claim that man: is exploitable to make things clear.
Created attachment 272877 [details] [diff] [review] Proposed fix This basically gives branch parity with trunk....
10 years ago
Unsetting blocking1.9, since this is not a problem on trunk.
10 years ago
(In reply to comment #24) > Created an attachment (id=272877) [details] > Proposed fiix > > This basically gives branch parity with trunk.... > if i understand correctly trunk is not completely safe. on trunk pasting in location bar "sftp://shared/tmp/own.html" reads files on "shared". "own.html" <iframe src="/" id='if1'></iframe> <script> setTimeout('alert(document.all.if1.contentDocument.body.innerHTML)',2000);
On trunk, users can of their own volition load sftp:// URIs and any sftp:// URI can access any other sftp:// URI on the same host and start the load of any sftp:// URI whatsoever. That's the general model we have for protocol handlers, and we don't really want to change it. I agree that this is not a great fit for sftp://, and I'd be happy to remove sftp:// support altogether. In fact, personally I'd be happy to remove the gnomevfs protocol handler support altogether. A google search doesn't indicate the preference being used, particularly, so presumably people are only using it for smb:// and sftp://... I do see value in the smb:// handler, but I don't think we can make the sftp:// one all that much safer than it is on trunk right now.
don't have samba server to test but Comment #15 shows smb:// may cache credentials so sftp and smb seem close to bugs and functionality. if you ask me ditch both sftp and smb, but ditching things seems unpopular idea.
Comment on attachment 272877 [details] [diff] [review] Proposed fix r=dveditz
Comment on attachment 272877 [details] [diff] [review] Proposed fix Requesting branch approvals
does this patch mean dropping support for gnomevfs?
No, it means disallowing unprivileged content from linking to these schemes.
so 1. nothing is whitelisted for untrusted content 2. pasting in location bar still works 3. clicking on external protocol handlers gives a warning about a buggy handler?
Not sure what you mean by item 3
i mean this patch doesn't change man:ls and data:text/html;,<a href="man:ls">man</a>
Comment on attachment 272877 [details] [diff] [review] Proposed fix approved for 188.8.131.52 and 184.108.40.206, a=dveditz for release-drivers
Fixed on both branches. Not an issue on trunk.
G30rgi, could you help us verify this bug fix in FF2008rc2?
testcases are attachments in this bug: sftp-main.html and /tmp/sftp1.html verfified fixed on: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:220.127.116.11pre) Gecko/20071012 BonEcho/18.104.22.168pre Security Error: Content at http://localhost:8080/sftp-main.html may not load or link to sftp://localhost/tmp/sftp1.html.
the port (8080) doesn't matter - got the same error with port 8080 in the sftp schema.
in addition sftp1.html may be on different sshd server, not on the httpd host.
Marking as in-litmus-. The steps to verify in comment 42 are more complex and technical than we would expect from testers. As such, it is beyond the scope of Litmus. A test case of this nature in Litmus would have to involve steps for setting up an httpd and sshd server, completely bloating the test case. I think we are probably safe to just refer back to comment 42 should we need to test this in the future. Feel free to comment with further suggestions.