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
