Last Comment Bug 381146 - (CVE-2007-5337) [FIX]sftp protocol allows file stealing under certain circumstances
(CVE-2007-5337)
: [FIX]sftp protocol allows file stealing under certain circumstances
Status: VERIFIED FIXED
[sg:investigate] not on trunk
: fixed1.8.0.14, fixed1.8.1.8
Product: Core
Classification: Components
Component: Security (show other bugs)
: 1.8 Branch
: x86 Linux
: -- major (vote)
: ---
Assigned To: Boris Zbarsky [:bz] (Out June 25-July 6)
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-18 02:57 PDT by georgi - hopefully not receiving bugspam
Modified: 2009-05-20 16:55 PDT (History)
18 users (show)
dveditz: wanted1.8.1.x+
dveditz: wanted1.8.0.x+
anthony.s.hughes: in‑litmus-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
sftp-main.html (214 bytes, text/html)
2007-05-18 02:57 PDT, georgi - hopefully not receiving bugspam
no flags Details
/tmp/sftp1.html (329 bytes, text/html)
2007-05-18 02:58 PDT, georgi - hopefully not receiving bugspam
no flags Details
Proposed fix (4.23 KB, patch)
2007-07-18 15:54 PDT, Boris Zbarsky [:bz] (Out June 25-July 6)
dveditz: review+
jst: superreview+
dveditz: approval1.8.1.8+
dveditz: approval1.8.0.14+
Details | Diff | Review

Description georgi - hopefully not receiving bugspam 2007-05-18 02:57:15 PDT
Created attachment 265238 [details]
sftp-main.html

sftp protocol allows file stealing under certain circumstances

SARVER is a ssh server with sftp and key auth enabled.
luser is a (privileged user) that may connect to SARVER via sftp/ssh via
key auth (~/.ssh/id_(r,d)sa empty passphrase and has SARVER in
~/.known_hosts)

basically via sftp SARVER looks like a web server- note
that the luser's private key gives him access to his private files -
$HOME.

attacker places sftp1.html on SARVER so that it is readadble by luser.
URIs look like:
[1] sftp://SARVER/tmp/sftp1.html
[2] sftp://SARVER/home/luser/.bash_history

[1] may read [2] via javascript.
[1] may be loaded in iframe via anywhere

in addition if luser's ssh settings do not strict host checking, sftp uris
will send his user name and public key to ssh servers - this is similar to
cookies, though such dumbness doesn't seem common.
Comment 1 georgi - hopefully not receiving bugspam 2007-05-18 02:58:28 PDT
Created attachment 265239 [details]
/tmp/sftp1.html
Comment 2 Daniel Veditz [:dveditz] 2007-05-18 11:30:11 PDT
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?
Comment 3 georgi - hopefully not receiving bugspam 2007-05-18 13:08:26 PDT
(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.

Comment 4 georgi - hopefully not receiving bugspam 2007-05-18 13:25:09 PDT
the rebranded kubuntu firefox 2.0.0.3 doesn't have sftp support.

branded firefox from ftp.mozilla.org does have sftp support.
Comment 5 georgi - hopefully not receiving bugspam 2007-05-18 13:31:09 PDT
the kubuntu firefox has "--enable-gnome-vfs", gnome-vfs isn't installed on kubuntu and sftp still works on official builds. 
Comment 6 georgi - hopefully not receiving bugspam 2007-06-04 00:13:48 PDT
linux cvs trunk doesn't recognize sftp if this matters with default debug build.
Comment 7 georgi - hopefully not receiving bugspam 2007-06-04 00:23:26 PDT
support of sftp protocol:

ff 2.0.0.4 from  m.o.: yes
ff trunk from m.o.: no
ff cvs debug trunk: no
kubuntu 7.0.4 ff 2.0.0.3: no
ubuntu 6.0.6 ff 1.5.0.11: yes
Comment 8 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-06-04 00:49:49 PDT
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.
Comment 9 georgi - hopefully not receiving bugspam 2007-06-04 04:34:22 PDT
(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?


Comment 10 georgi - hopefully not receiving bugspam 2007-06-04 04:58:45 PDT
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.
Comment 11 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-06-04 09:58:50 PDT
> 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?
Comment 12 georgi - hopefully not receiving bugspam 2007-06-04 10:27:05 PDT
(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.

Comment 13 georgi - hopefully not receiving bugspam 2007-06-04 10:32:56 PDT
this is strange about smb - it works:

data:text/html;,<iframe src="smb:///" />
Comment 14 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-06-04 10:37:45 PDT
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...
Comment 15 georgi - hopefully not receiving bugspam 2007-06-04 10:45:01 PDT
(In reply to comment #14)
> 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...
> 

it works from web page also (2.0 only, trunk complains).

btw, if the data uri is chrome javascript will do greater damage.

smb doesn't seem safe:
smb-method.c       DEBUG_SMB(("[auth] Saved in cache: %s = %s:%s@%s\n", key, actx->use_user, actx->use_domain, actx->use_password));

	DEBUG_SMB(("[auth] Trying to prefill credentials for: %s\n", in_args.uri));


	DEBUG_SMB(("[auth] Saving credentials: %s = %s@%s:%s\n", in_args.uri, actx->use_user, actx->use_domain, actx->use_password));
	DEBUG_SMB(("[auth] Keyring: %s\n", actx->keyring));



Comment 16 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-06-04 10:50:27 PDT
Oh, 2.0.  Of course it works there.  Just like sftp.

> btw, if the data uri is chrome javascript will do greater damage.

Sure.  Which is why chrome should not load them (and data: URIs typed in the URL bar should not be chrome).

Can anyone see a reason to not disable the gnome-vfs stuff at least on branches and probably also on trunk?  Why did we add it anyway?
Comment 17 georgi - hopefully not receiving bugspam 2007-06-04 10:54:31 PDT
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
Comment 18 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-06-04 11:01:27 PDT
> 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.
Comment 19 georgi - hopefully not receiving bugspam 2007-06-04 11:05:59 PDT
aaa, it is in
firefox204/components/libnkgnomevfs.so
Comment 20 Mike Connor [:mconnor] 2007-06-30 20:06:22 PDT
restoring bz's nom...
Comment 21 georgi - hopefully not receiving bugspam 2007-07-11 04:09:26 PDT
another external protocol handlers are:

man:bash
on linux

and
x-man-page://bash
on macosx ppc
Comment 22 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-07-12 13:17:53 PDT
What does that have to do with this bug?
Comment 23 georgi - hopefully not receiving bugspam 2007-07-13 00:26:58 PDT
(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.
Comment 24 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-07-18 15:54:11 PDT
Created attachment 272877 [details] [diff] [review]
Proposed fix

This basically gives branch parity with trunk....
Comment 25 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-07-18 15:58:03 PDT
Unsetting blocking1.9, since this is not a problem on trunk.
Comment 26 georgi - hopefully not receiving bugspam 2007-07-19 01:58:23 PDT
(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);
Comment 27 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-07-19 11:38:20 PDT
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.
Comment 28 georgi - hopefully not receiving bugspam 2007-07-20 08:11:57 PDT
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 29 Daniel Veditz [:dveditz] 2007-08-30 11:43:27 PDT
Comment on attachment 272877 [details] [diff] [review]
Proposed fix

r=dveditz
Comment 30 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-08-30 20:12:23 PDT
Comment on attachment 272877 [details] [diff] [review]
Proposed fix

Requesting branch approvals
Comment 31 georgi - hopefully not receiving bugspam 2007-08-30 22:29:00 PDT
does this patch mean dropping support for gnomevfs? 
Comment 32 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-08-30 23:27:38 PDT
No, it means disallowing unprivileged content from linking to these schemes.
Comment 33 georgi - hopefully not receiving bugspam 2007-08-31 00:50:09 PDT
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?
Comment 34 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-08-31 00:51:33 PDT
Not sure what you mean by item 3
Comment 35 georgi - hopefully not receiving bugspam 2007-08-31 01:24:47 PDT
i mean this patch doesn't change
man:ls
and
data:text/html;,<a href="man:ls">man</a>
Comment 36 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-08-31 12:33:35 PDT
That's correct.
Comment 37 Daniel Veditz [:dveditz] 2007-09-07 10:42:54 PDT
Comment on attachment 272877 [details] [diff] [review]
Proposed fix

approved for 1.8.1.7 and 1.8.0.14, a=dveditz for release-drivers
Comment 38 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-09-13 11:50:36 PDT
Fixed on both branches.  Not an issue on trunk.
Comment 39 juan becerra [:juanb] 2007-10-12 15:50:20 PDT
G30rgi, could you help us verify this bug fix in FF2008rc2? 
Comment 40 georgi - hopefully not receiving bugspam 2007-10-13 01:25:14 PDT
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:1.8.1.8pre) Gecko/20071012 BonEcho/2.0.0.8pre

Security Error: Content at http://localhost:8080/sftp-main.html may not load or link to sftp://localhost/tmp/sftp1.html.
Comment 41 georgi - hopefully not receiving bugspam 2007-10-13 01:26:59 PDT
the port (8080) doesn't matter - got the same error with port 8080 in the sftp schema.
Comment 42 georgi - hopefully not receiving bugspam 2007-10-13 02:27:12 PDT
instructions how to verify this.

one needs a server running httpd and sshd.

user must be able to log via ssh on server with key authentication without being asked for input - to do this, user generates a key via SSH-KEYGEN(1) - man ssh-keygen, then appends ~/id_rsa.pub (or ~/id_dsa_pub) to SERVER:~/.ssh/authorized_keys2 - at this point ssh user@server should give a shell on SERVER without asking for password (host fingerprint may be accepted once)

attachment /tmp/sftp1.html in this bug is copied on SERVER in /tmp and must be world readable (or readable by the victim).
in SERVER/tmp/sftp1.html
<iframe id="i1" src="/home/USER"></iframe>
change USER to the the victim name or a filename readable by victim.
when USER enters in location bar
sftp://SERVER/tmp/sftp1.html
he should see an iframe and alert with the directory/file.

now the attack:
place sftp-main.html from this bug on the web server.
when USER opens sftp-main.html via http, it opens sftp1.html via sftp and /home/USER is read via sftp and javascript.



Comment 43 georgi - hopefully not receiving bugspam 2007-10-13 02:54:07 PDT
in addition sftp1.html may be on different sshd server, not on the httpd host.
Comment 44 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2009-05-20 16:55:53 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.