I would say that with systems where you can actually use a scheme ("http://";)
as a file name (or folder, or something like that), there should be an
indication that this is a file and not a URL, just for the sake of phishing
protection. Even put a red strike (like you do with invalid https) on the
'fake scheme' part, just so the user will be somewhat notified.
☆PhistucK
On Thu, Jan 14, 2010 at 19:15, Scott Hess <sh...@google.com> wrote:
> On Thu, Jan 14, 2010 at 6:56 AM, Victor Khimenko <k...@google.com> wrote:
> > On Thu, Jan 14, 2010 at 5:38 PM, Scott Hess <sh...@google.com> wrote:
> >> On Thu, Jan 14, 2010 at 1:31 AM, Victor Khimenko <k...@google.com>
> wrote:
> >> > Consider this attack vector: URL file on Desktop. Chrome will be
> started
> >> > from known directory, now we need to put malicious file there. Hmm.
> >> > Easy:
> >> > create archive with some valuable data AND file http:/www.google.com(as
> >> > we've dicussed it's valid filename on Linux and MacOS). A lot of users
> >> > will
> >> > just unpack it on desktop and ignore some strange folder named "http".
> >> > Then
> >> > they click on URL file and the data from computer is sent to some
> >> > unknown
> >> > direction.
> >>
> >> I'm not really sure where you're going, here. Why would this be any
> >> different than convincing the user to click on a .html file?
> >
> > It's different because user is hosed when he clicks CORRECT AND VALID
> file -
> > at least the file which was correct and valid some time in the past. User
> > DOES NOT click on the malicious http folder - he uses the same citibank
> link
> > he always used. It the same as difference between NULL dereference and
> > uninitialized variable - in first case problem is immediately obvious, in
> > the the second one between error point and disaster there are millions of
> > commands so it's not easy to see the connection.
>
> There is no clicking, here. It's when the user launches Chrome on the
> command-line with a particular file.
>
> Unless I misunderstand. For any programmatic system which wishes to
> launch Chrome with a command-line argument, we should expect them to
> be explicit (file:/...), and if they choose to pass us ambiguous
> input, there's only so much we can do. I would hope that programmatic
> systems aren't passing us relative command-line filenames, though,
> it's hard to have one program treat relative paths consistently,
> expecting two to address them with the same assumptions is madness.
>
> >> Chrome's various protections are based on where Chrome is getting the
> >> file from, not on the shape of the URL (if you open a file named
> >> "https://citibank.com";, that file will NOT get the citibank.com
> >> secure cookie, etc).
> >>
> > Of course not - but if you'll open the file https://citibank.com it
> still
> > can do a lot of stuff to your account. It's not the end of world, but
> it's
> > not a trivial matter either. There are no separate domain for file named
> > http:/citibank.com and for file named ../.ssh/identity :-) Of course
> there
> > are other security measures which will hopefully save ../.ssh/identity
> file,
> > but it does not mean we are free to ignore this threat.
>
> As I said, if convincing me to click on a local file can result in an
> attacker receiving arbitrary files from my system, then we are well
> and truly screwed.
>
> But I don't believe that is the case currently, so I don't think it
> would change anything if the file is "http:/something.com" rather than
> "something.html". Yes, the user could be confused by the first URL
> (though Chrome would show "file:///full/path/http:/something.com"),
> but the attack surface is not changed. People load local HTML files
> all the time. If doing so could trivially expose sensitive local
> files like your ssh identity, then we should be talking about not
> allowing local files at all, not about what types of names we should
> allow.
>
> -scott
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
> http://groups.google.com/group/chromium-dev
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
