Security advice for linux browsers based on WebKit
If you don't use WebKit to build a browser on Linux, you can ignore this message. By default, WebKit allows local HTML files to inject script into any web page. That means that if you open a local HTML file on your machine, it can effective XSS every web site, including the user's bank or webmail provider. To protect against this threat, we have the following setting Settings::setAllowUniversalAccessFromFileURLs which disables this behavior. For legacy reasons, we default this setting to "true," but I'd like to encourage to use the "false" setting by default in your browser, especially if your browser runs on Linux. This issue is particularly important on Linux because many Linux users use a network file system, such as AFS or NFS, which maps the entire world into the local file system. For example, if I made my home directly world-readable, it's quite likely that I would be able to control this URL on your user's machines: file:///afs/cs.stanford.edu/u/abarth If you don't override WebKit's default setting, I might be able to leverage this ability to read your user's email or transact on your user's bank accounts. Of course, even with the "false" setting, I might still be able to read the contents of your user's /etc/passwd file or other sensitive information in your user's file system. Over time, I hope we can further restrict the privileges granted to file URLs. However, removing universal access is a necessary first step. Please let me know if you have any questions. Adam
On Sat, 2009-08-22 at 22:05 -0700, Adam Barth wrote:
which disables this behavior. For legacy reasons, we default this setting to "true," but I'd like to encourage to use the "false" setting by default in your browser, especially if your browser runs on Linux.
This issue is particularly important on Linux because many Linux users use a network file system, such as AFS or NFS, which maps the entire world into the local file system. For example, if I made my home directly world-readable, it's quite likely that I would be able to control this URL on your user's machines:
I notice that WebKitGTK+ disables this by default, good =). I think, though, that the AFS/NFS issue you mention is more general and shouldn't be a motivating factor. We have many GNU/Linux users not in corporate networks, these days, as well, and I think we should not be designing everything for big installations (those usually have admins who can worry about this kind of issue). Also, it looks like you can access windows shares using file://server/folder/file.html, so this doesn't seem to be UNIX-specific in any way. I also bet Mac can be made to use NFS, and AFS, so, again, I fail to see this as particularly important on non-Mac UNIX-likes. See you, -- Gustavo Noronha Silva <gns@gnome.org> GNOME
On Sun, Aug 23, 2009 at 9:02 PM, Gustavo Noronha Silva<gns@gnome.org> wrote:
On Sat, 2009-08-22 at 22:05 -0700, Adam Barth wrote:
which disables this behavior. For legacy reasons, we default this setting to "true," but I'd like to encourage to use the "false" setting by default in your browser, especially if your browser runs on Linux.
This issue is particularly important on Linux because many Linux users use a network file system, such as AFS or NFS, which maps the entire world into the local file system. For example, if I made my home directly world-readable, it's quite likely that I would be able to control this URL on your user's machines:
I notice that WebKitGTK+ disables this by default, good =).
Awesome. :)
I think, though, that the AFS/NFS issue you mention is more general and shouldn't be a motivating factor. We have many GNU/Linux users not in corporate networks, these days, as well, and I think we should not be designing everything for big installations (those usually have admins who can worry about this kind of issue).
Also, it looks like you can access windows shares using file://server/folder/file.html, so this doesn't seem to be UNIX-specific in any way. I also bet Mac can be made to use NFS, and AFS, so, again, I fail to see this as particularly important on non-Mac UNIX-likes.
I'm not sure I quite followed your line of reasoning here. Are you suggesting that everyone should use the more secure setting or are you saying that you don't think this is an important security measure in non-enterprise settings? I agree that everyone should disable universal access for file URLs. In fact, I think we should make it the default because the current default is pretty dangerous. Adam
On Sun, 2009-08-23 at 21:30 -0700, Adam Barth wrote:
I think, though, that the AFS/NFS issue you mention is more general and shouldn't be a motivating factor. We have many GNU/Linux users not in corporate networks, these days, as well, and I think we should not be designing everything for big installations (those usually have admins who can worry about this kind of issue).
Also, it looks like you can access windows shares using file://server/folder/file.html, so this doesn't seem to be UNIX-specific in any way. I also bet Mac can be made to use NFS, and AFS, so, again, I fail to see this as particularly important on non-Mac UNIX-likes.
I'm not sure I quite followed your line of reasoning here. Are you suggesting that everyone should use the more secure setting or are you saying that you don't think this is an important security measure in non-enterprise settings?
I am saying that we should be careful not to design things with 'Linux is mostly used in enterprise settings' in mind. There is no reason to treat it differently than the other desktops; I myself have never used NFS or AFS, nor have many people I know, even though I've been using GNU/Linux for ~10 years now. And, as I pointed out, the same potential problem with networked file systems may happen with Windows or Mac.
I agree that everyone should disable universal access for file URLs. In fact, I think we should make it the default because the current default is pretty dangerous.
So, to clear up my position regarding the actual meat of the proposal: I agree this is an important security concern. Doing that in libraries right now will break API expectations, though, so I think if it is done, this should be done first by documenting the intent to change, and then changing after a reasonable amount of time. Of course browser applications can do it right now, though =) See you, -- Gustavo Noronha Silva <gns@gnome.org> GNOME
On Mon, Aug 24, 2009 at 6:11 AM, Gustavo Noronha Silva<gns@gnome.org> wrote:
I am saying that we should be careful not to design things with 'Linux is mostly used in enterprise settings' in mind.
Ah, I see. Yes, this makes sense. My experience with Linux is mostly in universities where these sorts of file systems are the norm.
So, to clear up my position regarding the actual meat of the proposal: I agree this is an important security concern. Doing that in libraries right now will break API expectations, though, so I think if it is done, this should be done first by documenting the intent to change, and then changing after a reasonable amount of time. Of course browser applications can do it right now, though =)
By way of context, Firefox has had this mitigations for several years on all platforms. IE has an even more onerous mitigation for a long time (basically they punt the decision to the users with a "click here to be hacked" experience). Chrome has had this mitigation since day 1. I think the main compatibly risk is in non-browser uses of WebKit where it's difficult for us to assess the risk without knowing the application. Where do you think we should document our intent to change? Adam
Hi, I'm writing a webkit application which use only local files ( gramps-project ) I use python-webkit and pywebkitgtk. This is not a browser for the user. If I understand correctly, in a near futur, my application will not work. Is there a way to avoid this kind of problem ? Can we authorize one application to use local files ? I use in python : self.window = webkit.WebView() settings = self.window.get_settings() settings.set_property("enable-developer-extras", True) Can we set this property too ? and how ? Does this mean python-webkit and pywebkitgtk should take care of this ? Adam Barth wrote:
If you don't use WebKit to build a browser on Linux, you can ignore this message.
By default, WebKit allows local HTML files to inject script into any web page. That means that if you open a local HTML file on your machine, it can effective XSS every web site, including the user's bank or webmail provider. To protect against this threat, we have the following setting
Settings::setAllowUniversalAccessFromFileURLs
which disables this behavior. For legacy reasons, we default this setting to "true," but I'd like to encourage to use the "false" setting by default in your browser, especially if your browser runs on Linux.
This issue is particularly important on Linux because many Linux users use a network file system, such as AFS or NFS, which maps the entire world into the local file system. For example, if I made my home directly world-readable, it's quite likely that I would be able to control this URL on your user's machines:
file:///afs/cs.stanford.edu/u/abarth
If you don't override WebKit's default setting, I might be able to leverage this ability to read your user's email or transact on your user's bank accounts.
Of course, even with the "false" setting, I might still be able to read the contents of your user's /etc/passwd file or other sensitive information in your user's file system. Over time, I hope we can further restrict the privileges granted to file URLs. However, removing universal access is a necessary first step.
Please let me know if you have any questions.
On Mon, Aug 24, 2009 at 10:23 AM, Serge Noiraud<Serge.Noiraud@laposte.net> wrote:
I'm writing a webkit application which use only local files ( gramps-project ) I use python-webkit and pywebkitgtk. This is not a browser for the user.
If I understand correctly, in a near futur, my application will not work. Is there a way to avoid this kind of problem ?
If you use only local files, you should be fine. The change we're discussing is about the interaction between local files and network resources.
Can we authorize one application to use local files ?
I use in python :
self.window = webkit.WebView() settings = self.window.get_settings() settings.set_property("enable-developer-extras", True)
Can we set this property too ? and how ? Does this mean python-webkit and pywebkitgtk should take care of this ?
If you do run into trouble, you should try setting Settings::setAllowUniversalAccessFromFileURLs to true explicitly. I'm not sure how/if that's exposed in python-webkit, but I imagine it will be similar to enable-developer-extras. Adam
On Mon, Aug 24, 2009 at 8:23 PM, Serge Noiraud<Serge.Noiraud@laposte.net> wrote:
Hi,
I'm writing a webkit application which use only local files ( gramps-project ) I use python-webkit and pywebkitgtk. This is not a browser for the user.
If I understand correctly, in a near futur, my application will not work. Is there a way to avoid this kind of problem ? Can we authorize one application to use local files ?
I use in python :
self.window = webkit.WebView() settings = self.window.get_settings() settings.set_property("enable-developer-extras", True)
Can we set this property too ? and how ? Does this mean python-webkit and pywebkitgtk should take care of this ?
Yes, starting from WebKitGTK+ 1.1.13 (and when the python bindings catch up) you can do: settings.set_property("enable-universal-access-from-file-uris", True) assuming you know what you are doing :) Cheers, Xan
Hi Adam, I think it's probably possible to change the default on all platforms other than Mac. I do not believe the compatibility issues we're concerned about for Mac affect any other port. I think this would be a good choice. For what it's worth, NFS/AFS automounting also affects many Mac OS X deployments. We may have to take special measures to detect remote mountpoints to mitigate these risks. Regards, Maciej On Aug 22, 2009, at 10:05 PM, Adam Barth wrote:
If you don't use WebKit to build a browser on Linux, you can ignore this message.
By default, WebKit allows local HTML files to inject script into any web page. That means that if you open a local HTML file on your machine, it can effective XSS every web site, including the user's bank or webmail provider. To protect against this threat, we have the following setting
Settings::setAllowUniversalAccessFromFileURLs
which disables this behavior. For legacy reasons, we default this setting to "true," but I'd like to encourage to use the "false" setting by default in your browser, especially if your browser runs on Linux.
This issue is particularly important on Linux because many Linux users use a network file system, such as AFS or NFS, which maps the entire world into the local file system. For example, if I made my home directly world-readable, it's quite likely that I would be able to control this URL on your user's machines:
file:///afs/cs.stanford.edu/u/abarth
If you don't override WebKit's default setting, I might be able to leverage this ability to read your user's email or transact on your user's bank accounts.
Of course, even with the "false" setting, I might still be able to read the contents of your user's /etc/passwd file or other sensitive information in your user's file system. Over time, I hope we can further restrict the privileges granted to file URLs. However, removing universal access is a necessary first step.
Please let me know if you have any questions.
Adam _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Mon, Aug 24, 2009 at 7:16 PM, Maciej Stachowiak<mjs@apple.com> wrote:
I think it's probably possible to change the default on all platforms other than Mac. I do not believe the compatibility issues we're concerned about for Mac affect any other port. I think this would be a good choice.
I most definitely agree here. If there is no need to worry about compatibility on the other platforms I think it is a good idea to close down such a potential security threat by default. Platform porters may not realize there are such risky settings and could release insecure software as a result. Though they deserve some responsibility in that, it is also smart to try to prevent such problems at the WebKit level. -- Regards, Ryan
participants (6)
-
Adam Barth
-
Gustavo Noronha Silva
-
Maciej Stachowiak
-
Ryan Leavengood
-
Serge Noiraud
-
Xan Lopez