Sure. It's the way to exploit naive scheme (open local file, then try to open remote one if this fails). If you distinguish local/remote using filename only and don't involve the filesystem the scheme fails: people will not create shortcuts which don't work! And if they worked once they'll work the same way in the future...
On Thu, Jan 14, 2010 at 12:37 PM, PhistucK <[email protected]> wrote: > 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 <[email protected]> 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. >> >
-- Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
