381146 - (CVE-2007-5337) [FIX]sftp protocol allows file stealing under certain circumstances

Status: VERIFIED FIXED

(Core :: Security, defect)

Description

[georgi - hopefully not receiving bugspam]

Attachment: 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]

Attachment: /tmp/sftp1.html

Comment 2

[Daniel Veditz [:dveditz]]

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]

(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]

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]

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]

linux cvs trunk doesn't recognize sftp if this matters with default debug build.

Comment 7

[georgi - hopefully not receiving bugspam]

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 [:bzbarsky]]

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]

(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]

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 [:bzbarsky]]

> 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]

(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]

this is strange about smb - it works:

data:text/html;,<iframe src="smb:///" />

Comment 14

[Boris Zbarsky [:bzbarsky]]

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]

(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 [:bzbarsky]]

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]

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 [:bzbarsky]]

> 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]

aaa, it is in
firefox204/components/libnkgnomevfs.so

Comment 20

[Mike Connor [:mconnor]]

restoring bz's nom...

Comment 21

[georgi - hopefully not receiving bugspam]

another external protocol handlers are:

man:bash
on linux

and
x-man-page://bash
on macosx ppc

Comment 22

[Boris Zbarsky [:bzbarsky]]

What does that have to do with this bug?

Comment 23

[georgi - hopefully not receiving bugspam]

(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 [:bzbarsky]]

Attachment: Proposed fix

This basically gives branch parity with trunk....

Comment 25

[Boris Zbarsky [:bzbarsky]]

Unsetting blocking1.9, since this is not a problem on trunk.

Comment 26

[georgi - hopefully not receiving bugspam]

(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 [:bzbarsky]]

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]

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]]

Comment on attachment 272877 [details] [diff] [review]
Proposed fix

r=dveditz

Comment 30

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 272877 [details] [diff] [review]
Proposed fix

Requesting branch approvals

Comment 31

[georgi - hopefully not receiving bugspam]

does this patch mean dropping support for gnomevfs? 

Comment 32

[Boris Zbarsky [:bzbarsky]]

No, it means disallowing unprivileged content from linking to these schemes.

Comment 33

[georgi - hopefully not receiving bugspam]

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 [:bzbarsky]]

Not sure what you mean by item 3

Comment 35

[georgi - hopefully not receiving bugspam]

i mean this patch doesn't change
man:ls
and
data:text/html;,<a href="man:ls">man</a>

Comment 36

[Boris Zbarsky [:bzbarsky]]

That's correct.

Comment 37

[Daniel Veditz [:dveditz]]

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 [:bzbarsky]]

Fixed on both branches.  Not an issue on trunk.

Comment 39

[juan becerra [:juanb]]

G30rgi, could you help us verify this bug fix in FF2008rc2? 

Comment 40

[georgi - hopefully not receiving bugspam]

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]

the port (8080) doesn't matter - got the same error with port 8080 in the sftp schema.

Comment 42

[georgi - hopefully not receiving bugspam]

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]

in addition sftp1.html may be on different sshd server, not on the httpd host.

Comment 44

[u279076]

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.