File URIs; was Re (6): Capability of Iceweasel to open a local file.
On 09/06/11 02:11, firstname.lastname@example.org wrote:
> Scott & others,
> From: Scott Ferguson <email@example.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.
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
>> files ...
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
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
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
Tuttle? His name's Buttle.
There must be some mistake.
We don't make mistakes.
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org