Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
On Thu, Jan 14, 2010 at 9:23 AM, Paweł Hajdan, Jr. phajdan...@chromium.orgwrote: 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
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
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 phist...@gmail.com 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 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. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
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. 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.comsecure 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. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] opening local files with chrome from command line, relative paths
On Sat, Jan 9, 2010 at 6:08 AM, Antoine Labour pi...@google.com wrote:
How about:
int fd = open(file_or_url, O_RDONLY);
if (fd = 0) {
close(fd);
OpenLocalFile(file_or_url);
} else {
OpenURL(file_or_url);
}
Security risk. It's fine for interactive work (eve then it's risky), but
when script opens the file and you can shove local file where remote is
expected or vice versa... Think about it:
$ mkdir https:
$ echo test https://mail.google.com
$ cat https://mail.google.com
test
Oops?
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] opening local files with chrome from command line, relative paths
On Sat, Jan 9, 2010 at 2:55 PM, Antoine Labour pi...@google.com wrote: I'm not sure I understand the security risk... If an attacker is able to write files on my disk I have a lot more things to worry about than my browser spoofing urls. Are you sure? The idea is the same as with $PATH attack. Sure, some systems don't even need . in PATH to call programs from current dir by default, but it does make it good idea. In any case you can always OpenURL(string(file://) + urlencode(file_or_url)) instead of OpenLocalFile What will this change? There are sad but fundamental truth about POSIX filenames: ANY string without embedded NUL characters can be valid filename. There are some limitations (MAX_PATH, max number of slashes in some systems, etc), but they are minor. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] opening local files with chrome from command line, relative paths
What OS is it? What FS ? I've checked with GHardy - everything works just fine. You can create filenames with :, , , etc. Anything except / but then it's compensated by the fact that duplicated slashes are ignored. Cygwin works too (starting from version 1.7 where support for POSIX FS namespace was added) even if it's pretty irrelevant to Chrome discussion... On Sat, Jan 9, 2010 at 5:28 PM, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: Bash won't let me do this: $ mkdir https: mkdir: cannot create directory `https:': No such file or directory $ mkdir https: mkdir: cannot create directory `https:': No such file or director 2010/1/9 Victor Khimenko k...@google.com On Sat, Jan 9, 2010 at 2:55 PM, Antoine Labour pi...@google.com wrote: I'm not sure I understand the security risk... If an attacker is able to write files on my disk I have a lot more things to worry about than my browser spoofing urls. Are you sure? The idea is the same as with $PATH attack. Sure, some systems don't even need . in PATH to call programs from current dir by default, but it does make it good idea. In any case you can always OpenURL(string(file://) + urlencode(file_or_url)) instead of OpenLocalFile What will this change? There are sad but fundamental truth about POSIX filenames: ANY string without embedded NUL characters can be valid filename. There are some limitations (MAX_PATH, max number of slashes in some systems, etc), but they are minor. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Pierre. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] opening local files with chrome from command line, relative paths
CygWin is not POSIX system. It tries to emulate POSIX as much as feasible but version 1.5, for example, does not even use POSIX filesystem namespace! Anyway I've checked: latest stable version (1.7.1-1) works just fine here. You can create directory http: - but it'll look really funny in Explorer and other Windows-native programs (CygWin can not put this name in Windows-native slot so it creates some surrogate to put there). P.S. There are interesting fact related to specifically colon and MacOS. Classic MacOS uses colon as delimeter and you can use slash in filename. when they used POSIX-compliat kernel they needed some way to resolve thus collision. The solution was simple and elegant: they swapped colon and slash - so if you'll create http: directory old MacOS 9 program will see http/ directory. Thus you can create file which looks as http://google.com; for unix-programs and for MacOS programs (even if it'll be two different files). On Sun, Jan 10, 2010 at 12:45 AM, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: Actually it was Cygwin on Windows Vista (GNU bash, version 3.2.49(22)-release (i686-pc-cygwin) Copyright (C) 2007 Free Software Foundation, Inc.). However this isn't very important with regards to the point you're trying to make. I was just curious. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Don't use Empty[String,WString,String16,GURL]() unless you really need to
On Fri, Jan 8, 2010 at 2:10 AM, Albert J. Wong (王重傑) ajw...@chromium.orgwrote:
According to wikipedia,
http://en.wikipedia.org/wiki/Return_value_optimization, msvc, g++, and
icc, all support it...or am I missing something about this situation that
makes RVO inapplicable?
Yes. Starting from version 3.1: http://gcc.gnu.org/gcc-3.1/changes.html
G++ now supports the named return value optimization: for code like
A f () {
A a;
...
return a;
}
G++ will allocate a in the return value slot, so that the return becomes a
no-op. For this to work, all return statements in the function must return
the same variable
The limitation is still true AFAIK. Many compilers give up early in case
where function can return two objects depending on some condition.
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Don't use Empty[String,WString,String16,GURL]() unless you really need to
On Fri, Jan 8, 2010 at 1:51 AM, Albert J. Wong (王重傑) ajw...@chromium.orgwrote:
On Thu, Jan 7, 2010 at 2:46 PM, Darin Fisher da...@chromium.org wrote:
On Thu, Jan 7, 2010 at 1:34 PM, Jeremy Orlow jor...@chromium.org wrote:
(As discussed during lunch...) Why not just do this in this case and
remove EmptyString() altogether?
const std::string MyClass::foo() const {
static std::string empty = EmptyString();
return (everything == OK) ? member_string : empty;
}
This is not thread safe. EmptyString() uses SingletonT to basically
achieve the same thing in a thread safe manner.
Is there something wrong with returning by copy, and relying on the
compiler
to execute a return value optimization?
Do you volunteer to rewrite the compilers to implement said optimization?
GCC, for one will not do so.
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
