On 08/06/11 09:13, peasth...@shaw.ca wrote: > Hello Axel, > > From: Axel Freyn <axel-fr...@gmx.de> > Date: Tue, 07 Jun 2011 10:40:22 +0200 >> I have no webserver at hand, so I haven't tested ... > > But you don't need a server. You only need to find a link, on any > server anywhere, which targets a file URI. Then duplicate the file > in your own system. Use a link on my server if you want to try a test. > >> The serious security flaw which I see here is the following: This >> allows all remote site which you're looking at to use "file:///" in >> order to acces your local files. That's true also for javascript. > > But the remote site does nothing more serious than provide a file URI. > The file can't even execute unless it's executeable. For something bad to > occur the user would have to prearrange a dangerous executeable. Then > find and click a link targeting that executeable. Could all this happen > by accident? More likely for a blundering user to "cd ~; rm -r *"?
I seem to remember a number of URL handling exploits that could cause a problem (if they still exist). I definitely remember that as being the reason for closing that capability! :-( "file:///..." has been used in the past to view directories, and there are other variations. It seems an unnecessary risk. Have you considered running a tiny webserver on your local machine (monkey?) and serving the local file/s from that? > >> So, as >> soon as you set "security.checkloaduri=true", a website you're visiting >> could copy all files from your local disk which you're allowed to read >> (so /etc/shadow would be inaccessible (except you run iceweasel as root >> :-)), but all files in /home/user kann be copied). > > Only if the local user clicks on the link and the target does the malicious > deed. Why would such a dangerous target executeable be lying around? Only if something follows the link and does something you haven't thought of.... How can you determine such a thing is not possible? At the very least the intruder would gain dangerous insights into your OS, enabling them to find further exploits. But just knowing what files you have on your system is a risk. Decided it's best I don't post a working example of why not to do it. Tempting though... :-D <snipped> Interesting. I have a situation where I want a user to be able load local files from a (local) webpage - and use javascript to modify local files - so please post your outcome. Cheers -- Tuttle? His name's Buttle. There must be some mistake. Mistake? [Chuckles] We don't make mistakes. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4deed945.9030...@gmail.com
