FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 06-09-2011, 06:22 PM
 
Default File URI & security; was Re (2): File URIs

Scott,

You are have responsibility to users or clients. I am a user
trying to make a simple Web page. We have different views of
"reasonable caution".

From: Scott Ferguson <prettyfly.productions@gmail.com>
Date: Thu, 09 Jun 2011 17:07:44 +1000
> the classic was/is
> a login to Linux based networked web cam that could be bypassed by
> adding an extra slash to the URI

So the fault was in the cam. Not in a file URI.
Conclusion: don't buy hardware which tries to provide something
which should be done by decent software.

> 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.

See following.

> ... work on Windoof only.

Must we talk about that? =8-)

> Easier to copy the files to the root of the webserver
> than take a chance I think? :-)

Then I can change the target of the link from file:///home/peter/Category2.html
to http:///Category2.html or http://localhost/Category2.html .
The path to the file is no longer published. Good.

But a Web server shouldn't be necessary. What about making a link
/Category2.html which points at /home/peter/Category2.html ?
Then the published link file:///Category2.html doesn't reveal the path.

Is a Web server really needed just to get past this pesky security.checkloaduri?
Seems weird!

> The more information about your system available to an attacker - the
> greater the risk an attack will be successful.

Understood.

Any miscreant will know that a *nix system has user directories
in /home. With a quick glance at my network diagram he can deduce
the existence of dalton:/home/peter/. With a glance at one of my
public Web pages he knows that I have a file named Category2.html.
Therefore dalton:/home/peter/Category2.html might exist! But
dalton is firewalled and does not have Web server. The link anchor
[file:///home/peter/Category2.html] in a public page gives little
to the miscreant. Conversely, it allows me to test the page more
quickly.

> Yes. And axes are made for cutting wood.

Iceweasel's security.checkloaduri is analogous to a federal law
banning sale of axes. Of course, one can set up a forge and tools,
make the axe head and install a handle. Thankfully, we don't
have to do that to cut firewood!

> 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.

A2 has a Web server and to my knowledge there has never been a
security breach of that system. It might work for you except for
lack of javascript. What about Inferno? Make it as simple as
possible but not simpler.

> Just out of curiosity - is that webserver Apache running the ldap_mod?

The server for http://members.shaw.ca/peasthope/#Links belongs to Shaw.
http://www.shaw.ca/
The W3 validator reports "Server: Apache/2.2.15 (Unix) mod_ldap_userdir/1.1.17".
Click on the icon at the bottom of the page, click on "Verbose output"
and revalidate to see that.

> Did it allow you to serve a file outside of the public_html directory
> without modification?

We're at crossed purposes here. The link is in the page served by Shaw.
I see the link and view the file on dalton using the Iceweasel on dalton.
My network diagram shows. http://carnot.yi.org/NetworkExtant.jpg

BTW, my primary data storage is a CF card used in an ETHNO system.
There has never been a security breach of an ETHNO system. The chance
of injury from a miscreant is smaller than the risk of an earthquake
shaking the computer off the desk and onto me. =8~|

Regards, ... Peter E.

--
Telephone 1 360 450 2132. bcc: peasthope at shaw.ca
Shop pages http://carnot.yi.org/ accessible as long as the old drives survive.
Personal pages http://members.shaw.ca/peasthope/ .


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 171057033.42402.29997@cantor.invalid">http://lists.debian.org/171057033.42402.29997@cantor.invalid
 
Old 06-10-2011, 07:31 AM
Scott Ferguson
 
Default File URI & security; was Re (2): File URIs

On 10/06/11 04:22, peasthope@shaw.ca wrote:
> Scott,
>
> You are have responsibility to users or clients. I am a user
> trying to make a simple Web page. We have different views of
> "reasonable caution".

Yes. I am not reasonable. The severity of a scenario rates higher than
the likelihood. An intruder or malware gaining control/access is just as
worrying as a page not loading properly or a dead-link - clients
overlook uptime when there's any downtime.
I've also learnt that a secure architecture is only secure as long as
the applications that use it don't change - which is a rarity. HTML5,
cloud apps, ,IE9, CSS2, are all coming changes with unknown risks.

>> the classic was/is
>> a login to Linux based networked web cam that could be bypassed by
>> adding an extra slash to the URI
>
> So the fault was in the cam. Not in a file URI.

> Conclusion: don't buy hardware which tries to provide something
> which should be done by decent software.

It was software. An unpatched Apache vulnerability (from memory).
Nothing to do with hardware.

>
>> 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.
>
> See following.
>
>> ... work on Windoof only.

The rdp:// exploits were platform agnostic.

>
> Must we talk about that? =8-)

My intention was only to demonstrate that it's impossible to quantify
unknown risks...

>
>> Easier to copy the files to the root of the webserver
>> than take a chance I think? :-)
>
> Then I can change the target of the link from file:///home/peter/Category2.html
> to http:///Category2.html or http://localhost/Category2.html .
> The path to the file is no longer published. Good.

And you can then use .htaccess files to add additional control/security,
and to change that (apparent) path.

>
> But a Web server shouldn't be necessary. What about making a link
> /Category2.html which points at /home/peter/Category2.html ?
> Then the published link file:///Category2.html doesn't reveal the path.

Soft links'll work fine.

>
> Is a Web server really needed just to get past this pesky security.checkloaduri?

No. That's a different subject.

> Seems weird!

Don't it?
Now if you can link to the root of the web server that'll do the trick.


>
>> The more information about your system available to an attacker - the
>> greater the risk an attack will be successful.
>
> Understood.
>
> Any miscreant will know that a *nix system has user directories
> in /home. With a quick glance at my network diagram he can deduce
> the existence of dalton:/home/peter/. With a glance at one of my
> public Web pages he knows that I have a file named Category2.html.
> Therefore dalton:/home/peter/Category2.html might exist! But
> dalton is firewalled and does not have Web server. The link anchor
> [file:///home/peter/Category2.html] in a public page gives little
> to the miscreant. Conversely, it allows me to test the page more
> quickly.

Agreed.

>
>> Yes. And axes are made for cutting wood.
>
> Iceweasel's security.checkloaduri is analogous to a federal law
> banning sale of axes. Of course, one can set up a forge and tools,
> make the axe head and install a handle. Thankfully, we don't
> have to do that to cut firewood!

:-)
I meant web servers *are* for publishing html. Sometimes they are used
for purposes other than what (the owner/manager) intended. Ask Lizzie
Borden.

>
>> 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.
>
> A2 has a Web server and to my knowledge there has never been a
> security breach of that system. It might work for you except for
> lack of javascript. What about Inferno? Make it as simple as
> possible but not simpler.

The webpages only need to be accessed locally, the netbooks lack grunt
already, the support fees are very low - and I wont' be asked to do
support until they're completely broken (by which time Wheezy will be
stable), and I can run the application under a separate user account.
These are Eee 380Ds with 512MB of RAM running Squeeze Trinity - not a
lot of grunt available anyway. Tight margins all-round.

<snipped>
>
> BTW, my primary data storage is a CF card used in an ETHNO system.
> There has never been a security breach of an ETHNO system. The chance
> of injury from a miscreant is smaller than the risk of an earthquake
> shaking the computer off the desk and onto me. =8~|

No argument there.
Just suggesting you keep everything that is served by the webserver in
the one place. If not for security then for simplicity.

There are tens of thousands of insecure sites. I think you'll avoid
becoming a FakeMalware vendor - especially as you lack sql injection
vulnerabilities!

Cheers




--
Tuttle? His name's Buttle.
There must be some mistake.
Mistake? [Chuckles]
We don't make mistakes.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DF1C83C.1010900@gmail.com">http://lists.debian.org/4DF1C83C.1010900@gmail.com
 

Thread Tools




All times are GMT. The time now is 06:58 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org