[BTW, don't take my argument as support for allowing relative paths on
the command-line. It's such a low-volume use-case that I'd be
perfectly fine requiring explicit fully-qualified URLs and be done
with it. If it doesn't start with a protocol, we don't open it.
99.99% of the users who even would understand what we're talking about
could trivially write a shell script or alias to handle it, if they
care to.]
On Thu, Jan 14, 2010 at 9:15 AM, 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
