RE: Status of RFC 1738 -- 'ftp' URI scheme

> From: John Cowan [mailto:cowan@ccil.org] On Behalf Of John Cowan
> Sent: Friday, 07 January, 2011 20:45
> 
> Michael Wojcik scripsit:
> 
> > But obviously some users (possibly the majority) *would* want a
> > file-scheme URI treated as a UNC name. And while I might argue that
> > the principle of least surprise, the principle of least privilege,
and
> > a bias toward security all argue against that, those are arguments
> > that historically have not had a lot of traction among casual users
or
> > implementors of the software they use.
> 
> Please do argue, because I don't see how they apply.

Really? Fine. I'll make this brief, as I have better things to do.

Principle of least surprise: The "file" scheme has historically been
treated as referring only to local resources. Obviously where the OS
hides the distinction between local and remote resources (eg mounted NFS
filesystems on Unix, drive-mapped SMB shares on Windows), the file
scheme did not discriminate. But in those cases the authority component
of the file-scheme URI could be ignored by the URI consumer (user
agent), because such resources are made available as "virtually local"
ones *externally* to the consumer. The file scheme is not treated as a
network scheme by the consumer, and so its authority component
implicitly refers to the local system. Thus having a file scheme treated
as a network scheme is surprising.

For evidence of this, you need only see the recent demonstration that
the Adobe Flash can be broken on Windows using file-scheme URIs to
retrieve network resources. Clearly that's not something the sandbox
designers anticipated.[1]

Also, the file scheme obviously doesn't specify *what* network protocol
might be used to retrieve remote resources, so different implementations
might use different protocols. It undermines the whole idea of the
scheme portion of the URI.


Principle of least privilege: The file scheme doesn't need to be a
network scheme, on Windows or anywhere else. There are plenty of schemes
for retrieving network resources. If you want a URI that specifies SMB
access, then it's time to standardize the smb scheme. Overloading the
file scheme removes a useful and important distinction in favor of
unnecessary convenience.


Bias toward security: Allowing the file scheme to be used to request
arbitrary network resources expands the attack surface. If a file-scheme
consumer discards the authority (or rejects authorities that aren't
equivalent to the local system), it can still be used to address
non-local resources that are mapped into a local filesystem (NFS mounts
etc). But since those are configured explicitly and outside the scope of
the URI consumer, the URI consumer doesn't need to be concerned with
policing them. On the other hand, if a file-scheme consumer attempts to
resolve URIs with non-local authorities using some file access protocol
such as SMB, it potentially (and often easily) becomes an oracle for
probing possible network resources. It might be used to bypass
simplistic network protections. It might be leveraged for MITM attacks
and other ways of suborning credentials (eg hash substitution).


There have historically been many security issues with the NTLM
authentication mechanisms for SMB, including some documented less than a
year ago.[2] Many URI consumers make it easy to have URIs processed
automatically or with minimal user interaction (eg by using them as the
value of the src attribute for an img element on a web page). That's not
a good combination.

At this point it's probably impossible to get Microsoft and others to
remove this misfeature from their processing of file-scheme URIs on
Windows. However, I'd much rather see a standard for the file scheme
that strongly discourages (if not forbids) it, than one that endorses
it. It adds little of use and significant risk.


[1] http://www.theregister.co.uk/2011/01/07/adobe_flash_bypass/
[2] See eg CVE-2010-0231.

> 
> >
> > I suppose what I'm saying, then, is that I don't believe it's clear
> > that the UNC-mapping behavior is necessarily desirable, and more
> > discussion on the topic might be called for, if we're trying to
> > standardize the file scheme.
> 
> I think that's what we are doing.
> 
> --
> John Cowan    cowan@ccil.org    http://ccil.org/~cowan
> Nobody expects the RESTifarian Inquisition!  Our chief weapon is
> surprise ... surprise and tedium  ... tedium and surprise ....
> Our two weapons are tedium and surprise ... and ruthless disregard for
> unpleasant facts....  Our three weapons are tedium, surprise, and
> ruthless disregard ... and an almost fanatical devotion to Roy
> Fielding....
> 
> 
> This message has been scanned for viruses by MailController -
> www.MailController.altohiway.com

Received on Tuesday, 11 January 2011 19:07:43 UTC