But this way will not trigger the file access code (as far as I understand),
since you will start Chrome with an "http://";, which means it is a URL, so
Chrome will not open the file.
And even if they click on the file, it is a ".com" file, not a URL shortcut.
Or maybe I did not understand you correctly.
☆PhistucK
On Thu, Jan 14, 2010 at 11:31, Victor Khimenko <k...@google.com> wrote:
> On Thu, Jan 14, 2010 at 9:23 AM, Paweł Hajdan, Jr. <
> phajdan...@chromium.org> wrote:
>
>> Thanks for the responses. However, I'm not sure about the next steps.
>> Did you mean "it's a security risk, don't do it", or "the risk is
>> negligible, do it"? How about requiring a --file switch before a
>> relative file path is considered?
>>
>> I think it means that idea to try to open local file and it that fails
> open remote one as bad. The exact scheme which answers "should we try local
> file or remote file?" is not very important (Firefox scheme looks Ok to me),
> but the situation where EXACT SAME command line can open local file or
> remote one is surprising and dangerous.
>
> 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.
>
> --
> 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
