Note: There are a few cases of duplicates in user autocompletion which are being worked on.
Bug 381146 (CVE-2007-5337)

[FIX]sftp protocol allows file stealing under certain circumstances

VERIFIED FIXED

Status

()

Core
Security
--
major
VERIFIED FIXED
10 years ago
8 years ago

People

(Reporter: georgi - hopefully not receiving bugspam, Assigned: bz)

Tracking

({fixed1.8.0.14, fixed1.8.1.8})

1.8 Branch
x86
Linux
fixed1.8.0.14, fixed1.8.1.8
Points:
---
Bug Flags:
wanted1.8.1.x +
wanted1.8.0.x +
in-litmus -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:investigate] not on trunk)

Attachments

(3 attachments)

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.
Created attachment 265239 [details]
/tmp/sftp1.html
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?
Whiteboard: [sg:investigate]
(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 2.0.0.3 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 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
(Assignee)

Comment 8

10 years ago
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.
Severity: normal → major
Flags: blocking1.8.1.5?
Flags: blocking1.8.0.13?
(Assignee)

Updated

10 years ago
Flags: blocking-firefox3?
(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.
(Assignee)

Comment 11

10 years ago
> 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:///" />
(Assignee)

Comment 14

10 years ago
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...
(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));



(Assignee)

Comment 16

10 years ago
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?
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
(Assignee)

Comment 18

10 years ago
> 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
Flags: wanted1.8.1.x+
Flags: wanted1.8.0.x+
Flags: blocking1.8.1.5?
Flags: blocking1.8.0.13?

Updated

10 years ago
Assignee: nobody → dveditz
Component: Security → Security
Flags: blocking-firefox3?
Product: Firefox → Core
QA Contact: firefox → toolkit
Version: 2.0 Branch → Trunk
restoring bz's nom...
Flags: blocking1.9?

Updated

10 years ago
Flags: blocking1.9? → blocking1.9+
another external protocol handlers are:

man:bash
on linux

and
x-man-page://bash
on macosx ppc
(Assignee)

Comment 22

10 years ago
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.
(Assignee)

Comment 24

10 years ago
Created attachment 272877 [details] [diff] [review]
Proposed fix

This basically gives branch parity with trunk....
Assignee: dveditz → bzbarsky
Status: NEW → ASSIGNED
Attachment #272877 - Flags: superreview?(jst)
Attachment #272877 - Flags: review?
(Assignee)

Updated

10 years ago
Attachment #272877 - Flags: review? → review?(dveditz)
(Assignee)

Comment 25

10 years ago
Unsetting blocking1.9, since this is not a problem on trunk.
Flags: blocking1.9+
Summary: sftp protocol allows file stealing under certain circumstances → [FIX]sftp protocol allows file stealing under certain circumstances

Updated

10 years ago
Attachment #272877 - Flags: superreview?(jst) → superreview+
(Assignee)

Updated

10 years ago
Attachment #272877 - Attachment description: Proposed fiix → Proposed fix
(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);
(Assignee)

Comment 27

10 years ago
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
Attachment #272877 - Flags: review?(dveditz) → review+
(Assignee)

Comment 30

10 years ago
Comment on attachment 272877 [details] [diff] [review]
Proposed fix

Requesting branch approvals
Attachment #272877 - Flags: approval1.8.1.7?
Attachment #272877 - Flags: approval1.8.0.14?
does this patch mean dropping support for gnomevfs? 
(Assignee)

Comment 32

10 years ago
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?
(Assignee)

Comment 34

10 years ago
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>
(Assignee)

Comment 36

10 years ago
That's correct.
Whiteboard: [sg:investigate] → [sg:investigate] not on trunk
Version: Trunk → 1.8 Branch
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
Attachment #272877 - Flags: approval1.8.1.7?
Attachment #272877 - Flags: approval1.8.1.7+
Attachment #272877 - Flags: approval1.8.0.14?
Attachment #272877 - Flags: approval1.8.0.14+
(Assignee)

Comment 38

10 years ago
Fixed on both branches.  Not an issue on trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Keywords: fixed1.8.0.14, fixed1.8.1.7
Resolution: --- → FIXED
G30rgi, could you help us verify this bug fix in FF2008rc2? 
Whiteboard: [sg:investigate] not on trunk → [sg:investigate] not on trunk, [need testcase]
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.
Status: RESOLVED → VERIFIED
Whiteboard: [sg:investigate] not on trunk, [need testcase] → [sg:investigate] not on trunk
the port (8080) doesn't matter - got the same error with port 8080 in the sftp schema.
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.



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

Updated

10 years ago
Alias: CVE-2007-5337
Group: security
Flags: in-litmus?
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.
Flags: in-litmus? → in-litmus-
You need to log in before you can comment on or make changes to this bug.