On 09/06/11 02:11, peasth...@shaw.ca wrote: > Scott & others, > > From: Scott Ferguson <prettyfly.producti...@gmail.com> > Date: Wed, 08 Jun 2011 12:07:01 +1000 >> I seem to remember a number of URL handling exploits that could cause a >> problem (if they still exist). > > All the admonitions about security have been hypothetical. > Nobody has painted a convincing picture of a possible failure.
http://en.wikipedia.org/wiki/Directory_traversal URI exploits:- Most browsers will process any base64 or UTF as part of the URI and there have been a number of exploits that use base64 or UTF added to the published URI to view remote directories and files. (the classic was/is a login to Linux based networked web cam that could be bypassed by adding an extra slash to the URI). Then there's the buffer overflow URI exploits, and the remote protocol handling exploits where the protocol is changed on the published link. eg. file substituted with rdp etc. The majority of the (old) exploits I'm familiar with ('cause I've had to clean up the mess) work on Windoof only. As there are several directory traversal exploits for Linux based web browsers I couldn't rule out current or future ones. I don't know of any currently working URI exploits that would work on your specific setup, but I'm not a security expert. But for every Linux based URI exploit in Metasploit you can bet there's another dozen unpublished ones. :-( My personal policy is that with a "compelling argument" I won't take an unnecessary risk. Publishing links outside of my web server is an unnecessary risk. Easier to copy the files to the root of the webserver than take a chance I think? :-) > > My Links, including the file URIs, are public data. Bus schedules > for example. The file URIs are images expressed in html which I > want to publish. The Web is meant to allow publication! Yes. And axes are made for cutting wood. ;-p > >> 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 ... > > Your javascript is executeble isn't it? Yes. Any file can be made executable. Binaries can be modified. Text files can be modified. > That's your more risky circumstance. Yes. But that doesn't mean that non-executable files are without risk. Your bash history for instance - do you mount CIFS shares? Do you use a password file that's called by /etc/fstab? The more information about your system available to an attacker - the greater the risk an attack will be successful. This is an application that runs on Eee PCs without a webserver. It's a local app running on Iceweasel with NoScript installed. Never-the-less there is the potential for problems from local malware, or when connected to a network. That I can't list any hazards doesn't mean the application isn't vulnerable. To run it NoScript has to allow local files to run Javascript - which would then make it possible for malicious code in Iceweasel, NoScript - in fact any application that can access the browser, and probably more, to run. There may not even currently be a risk - but five years from now it could come back to bite me. (I don't control the netbooks, the client does). I'm all for open source code (and hardware), but I try and keep my systems closed. <snipped> Just out of curiosity - is that webserver Apache running the ldap_mod? Did it allow you to serve a file outside of the public_html directory without modification? 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/4df07140.2050...@gmail.com