You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Danny Angus (JIRA)" <ta...@jakarta.apache.org> on 2005/03/09 09:58:52 UTC
[jira] Commented: (TAPESTRY-278) Tapestry 3.0.2 asset service has security flaw
[ http://issues.apache.org/jira/browse/TAPESTRY-278?page=comments#action_60487 ]
Danny Angus commented on TAPESTRY-278:
--------------------------------------
This is a very significant issue which needs addressed as soon as possible.
> Tapestry 3.0.2 asset service has security flaw
> ----------------------------------------------
>
> Key: TAPESTRY-278
> URL: http://issues.apache.org/jira/browse/TAPESTRY-278
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 3.0.2
> Environment: Tomcat 5, JDK 1.4
> Reporter: Nathan Kopp
>
> The asset service can be used to view files that should not be visible. This could expose important resources, including database passwords and connection information.
> The asset service appears to expose any file relative to the classpath, and you can even use the ".." operator to go backwards, down into WEB-INF in general.
> Here are some examples. They were tested on a demo application which is often available on the web, but they've been "cleaned," so they don't point to a real server anymore:
> * View the web.xml file:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Fweb.xml
> * View the tapestry.application file:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2Ftapestry.application
> * View a raw JSP file:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2F..%2F..%2F404.jsp
> * Download a few class files that are part of the application:
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FMessageFilter.class
> http://www.someserver.com/tapestry-app/app?service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FBaseEngine.class
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [jira] Commented: (TAPESTRY-278) Tapestry 3.0.2 asset service
has security flaw
Posted by Robert Zeigler <rd...@u.arizona.edu>.
Erik Hatcher wrote:
> On Mar 9, 2005, at 8:21 PM, Robert Zeigler wrote:
>
>> Erik Hatcher wrote:
>>
>>> Prodding this issue.... thoughts? What do we want to do about
>>> this? Is blocking on file extension as a built-in patch good
>>> enough? What extensions should be allowed? Block paths with ".."
>>> also? Other stop-gap approaches?
>>
>>
>> I'm really not fond of blocking on file extensions.
>> Blocking paths with .. is a start, but still circumventable.
>> As I understand it, the asset service should provide access to assets
>> in any of the "context" subdirectories, except for WEB-INF, right?
>> (ie: MyWebApp/img.jpg, MyWebApp/images/img.jpg should both be
>> accessible via the asset service, but MyWebApp/WEB-INF/img.jpg should
>> not).
>> Since (if? =) this is the case, why not examine the directory
>> structure of the asset? You can do a recursive check to make sure
>> that the asset is not in a forbidden directory. Thoughts?
>
>
> The true beauty (and thus security hole) of the asset service is that
> it is designed to serve up content from libraries within the classpath.
> Consider DatePicker and its calendar icon and JavaScript code. You
> didn't put either of those above WEB-INF, did you? :) These are
> within the contrib JAR in WEB-INF/lib.
>
Heh. Sorry, too tired last night when I wrote in, I guess, and
completely forgot about private assets. =) I'll have to think on this a
bit.
> Please elaborate on how blocking with ".." is circumventable. (this
> would be a good start on a test case)
>
I read an interesting article on bugtraq at one point describing methods
whereby the .. can be cleverly escaped such that when all is said and
done, you still end up with a file with .. in the path. I don't remember
all of the details offhand; I'll see if I can dig up the article.
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [jira] Commented: (TAPESTRY-278) Tapestry 3.0.2 asset service has security flaw
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Mar 9, 2005, at 8:21 PM, Robert Zeigler wrote:
> Erik Hatcher wrote:
>> Prodding this issue.... thoughts? What do we want to do about this?
>> Is blocking on file extension as a built-in patch good enough?
>> What extensions should be allowed? Block paths with ".." also?
>> Other stop-gap approaches?
>
> I'm really not fond of blocking on file extensions.
> Blocking paths with .. is a start, but still circumventable.
> As I understand it, the asset service should provide access to assets
> in any of the "context" subdirectories, except for WEB-INF, right?
> (ie: MyWebApp/img.jpg, MyWebApp/images/img.jpg should both be
> accessible via the asset service, but MyWebApp/WEB-INF/img.jpg should
> not).
> Since (if? =) this is the case, why not examine the directory
> structure of the asset? You can do a recursive check to make sure that
> the asset is not in a forbidden directory. Thoughts?
The true beauty (and thus security hole) of the asset service is that
it is designed to serve up content from libraries within the classpath.
Consider DatePicker and its calendar icon and JavaScript code. You
didn't put either of those above WEB-INF, did you? :) These are
within the contrib JAR in WEB-INF/lib.
Please elaborate on how blocking with ".." is circumventable. (this
would be a good start on a test case)
Erik
> Robert
>
>> Howard mentioned via IM chat that adding an MD5 of the asset to the
>> URL and checking it before serving is something we should add
>> eventually.
>> Erik
>> On Mar 9, 2005, at 5:21 AM, Erik Hatcher wrote:
>>> I'm bringing this issue to the e-mail list. Many of us already knew
>>> this existed and it has been discussed here before but I've always
>>> used other techniques to block this hole. I agree its serious and
>>> needs to be corrected. What do folks suggest as the proper fix?
>>> Preventing ".." would be a quick and dirty way to stop path
>>> snooping, but also blocking all but a set of extensions would be
>>> needed.
>>>
>>> There are some workarounds:
>>>
>>> * use the asset externalization feature so that asset serving is
>>> from the container or web server rather than the asset service
>>> directly
>>> * use a servlet filter to block everything but .jpg/.gif/.png.
>>> Interestingly, my clean URL servlet filter on lucenebook.com thwarts
>>> the security hole.
>>>
>>> Howard - what do you see has a fix for this? This warrants a 3.0.3
>>> release IMO.
>>>
>>> Erik
>>>
>>>
>>> On Mar 9, 2005, at 3:58 AM, Danny Angus (JIRA) wrote:
>>>
>>>> [ http://issues.apache.org/jira/browse/TAPESTRY-278?
>>>> page=comments#action_60487 ]
>>>>
>>>> Danny Angus commented on TAPESTRY-278:
>>>> --------------------------------------
>>>>
>>>> This is a very significant issue which needs addressed as soon as
>>>> possible.
>>>>
>>>>> Tapestry 3.0.2 asset service has security flaw
>>>>> ----------------------------------------------
>>>>>
>>>>> Key: TAPESTRY-278
>>>>> URL: http://issues.apache.org/jira/browse/TAPESTRY-278
>>>>> Project: Tapestry
>>>>> Type: Bug
>>>>> Components: Framework
>>>>> Versions: 3.0.2
>>>>> Environment: Tomcat 5, JDK 1.4
>>>>> Reporter: Nathan Kopp
>>>>
>>>>
>>>>>
>>>>> The asset service can be used to view files that should not be
>>>>> visible. This could expose important resources, including
>>>>> database passwords and connection information.
>>>>> The asset service appears to expose any file relative to the
>>>>> classpath, and you can even use the ".." operator to go backwards,
>>>>> down into WEB-INF in general.
>>>>> Here are some examples. They were tested on a demo application
>>>>> which is often available on the web, but they've been "cleaned,"
>>>>> so they don't point to a real server anymore:
>>>>> * View the web.xml file:
>>>>> http://www.someserver.com/tapestry-app/app?
>>>>> service=asset&sp=S%2F..%2Fweb.xml
>>>>> * View the tapestry.application file:
>>>>> http://www.someserver.com/tapestry-app/app?
>>>>> service=asset&sp=S%2F..%2Ftapestry.application
>>>>> * View a raw JSP file:
>>>>> http://www.someserver.com/tapestry-app/app?
>>>>> service=asset&sp=S%2F..%2F..%2F404.jsp
>>>>> * Download a few class files that are part of the application:
>>>>> http://www.someserver.com/tapestry-app/app?
>>>>> service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FMessageFilter.class
>>>>> http://www.someserver.com/tapestry-app/app?
>>>>> service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FBaseEngine.class
>>>>
>>>>
>>>> --
>>>> This message is automatically generated by JIRA.
>>>> -
>>>> If you think it was sent incorrectly contact one of the
>>>> administrators:
>>>> http://issues.apache.org/jira/secure/Administrators.jspa
>>>> -
>>>> If you want more information on JIRA, or have a bug to report see:
>>>> http://www.atlassian.com/software/jira
>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> -
>>>> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail:
>>>> tapestry-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [jira] Commented: (TAPESTRY-278) Tapestry 3.0.2 asset service
has security flaw
Posted by Robert Zeigler <rd...@u.arizona.edu>.
Erik Hatcher wrote:
> Prodding this issue.... thoughts? What do we want to do about this?
> Is blocking on file extension as a built-in patch good enough? What
> extensions should be allowed? Block paths with ".." also? Other
> stop-gap approaches?
I'm really not fond of blocking on file extensions.
Blocking paths with .. is a start, but still circumventable.
As I understand it, the asset service should provide access to assets
in any of the "context" subdirectories, except for WEB-INF, right?
(ie: MyWebApp/img.jpg, MyWebApp/images/img.jpg should both be accessible
via the asset service, but MyWebApp/WEB-INF/img.jpg should not).
Since (if? =) this is the case, why not examine the directory structure
of the asset? You can do a recursive check to make sure that the asset
is not in a forbidden directory. Thoughts?
Robert
>
> Howard mentioned via IM chat that adding an MD5 of the asset to the URL
> and checking it before serving is something we should add eventually.
>
> Erik
>
>
>
> On Mar 9, 2005, at 5:21 AM, Erik Hatcher wrote:
>
>> I'm bringing this issue to the e-mail list. Many of us already knew
>> this existed and it has been discussed here before but I've always
>> used other techniques to block this hole. I agree its serious and
>> needs to be corrected. What do folks suggest as the proper fix?
>> Preventing ".." would be a quick and dirty way to stop path snooping,
>> but also blocking all but a set of extensions would be needed.
>>
>> There are some workarounds:
>>
>> * use the asset externalization feature so that asset serving is
>> from the container or web server rather than the asset service directly
>> * use a servlet filter to block everything but .jpg/.gif/.png.
>> Interestingly, my clean URL servlet filter on lucenebook.com thwarts
>> the security hole.
>>
>> Howard - what do you see has a fix for this? This warrants a 3.0.3
>> release IMO.
>>
>> Erik
>>
>>
>> On Mar 9, 2005, at 3:58 AM, Danny Angus (JIRA) wrote:
>>
>>> [ http://issues.apache.org/jira/browse/TAPESTRY-278?
>>> page=comments#action_60487 ]
>>>
>>> Danny Angus commented on TAPESTRY-278:
>>> --------------------------------------
>>>
>>> This is a very significant issue which needs addressed as soon as
>>> possible.
>>>
>>>> Tapestry 3.0.2 asset service has security flaw
>>>> ----------------------------------------------
>>>>
>>>> Key: TAPESTRY-278
>>>> URL: http://issues.apache.org/jira/browse/TAPESTRY-278
>>>> Project: Tapestry
>>>> Type: Bug
>>>> Components: Framework
>>>> Versions: 3.0.2
>>>> Environment: Tomcat 5, JDK 1.4
>>>> Reporter: Nathan Kopp
>>>
>>>
>>>>
>>>> The asset service can be used to view files that should not be
>>>> visible. This could expose important resources, including database
>>>> passwords and connection information.
>>>> The asset service appears to expose any file relative to the
>>>> classpath, and you can even use the ".." operator to go backwards,
>>>> down into WEB-INF in general.
>>>> Here are some examples. They were tested on a demo application
>>>> which is often available on the web, but they've been "cleaned," so
>>>> they don't point to a real server anymore:
>>>> * View the web.xml file:
>>>> http://www.someserver.com/tapestry-app/app?
>>>> service=asset&sp=S%2F..%2Fweb.xml
>>>> * View the tapestry.application file:
>>>> http://www.someserver.com/tapestry-app/app?
>>>> service=asset&sp=S%2F..%2Ftapestry.application
>>>> * View a raw JSP file:
>>>> http://www.someserver.com/tapestry-app/app?
>>>> service=asset&sp=S%2F..%2F..%2F404.jsp
>>>> * Download a few class files that are part of the application:
>>>> http://www.someserver.com/tapestry-app/app?
>>>> service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FMessageFilter.class
>>>> http://www.someserver.com/tapestry-app/app?
>>>> service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FBaseEngine.class
>>>
>>>
>>> --
>>> This message is automatically generated by JIRA.
>>> -
>>> If you think it was sent incorrectly contact one of the administrators:
>>> http://issues.apache.org/jira/secure/Administrators.jspa
>>> -
>>> If you want more information on JIRA, or have a bug to report see:
>>> http://www.atlassian.com/software/jira
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [jira] Commented: (TAPESTRY-278) Tapestry 3.0.2 asset service has security flaw
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
Prodding this issue.... thoughts? What do we want to do about this?
Is blocking on file extension as a built-in patch good enough? What
extensions should be allowed? Block paths with ".." also? Other
stop-gap approaches?
Howard mentioned via IM chat that adding an MD5 of the asset to the URL
and checking it before serving is something we should add eventually.
Erik
On Mar 9, 2005, at 5:21 AM, Erik Hatcher wrote:
> I'm bringing this issue to the e-mail list. Many of us already knew
> this existed and it has been discussed here before but I've always
> used other techniques to block this hole. I agree its serious and
> needs to be corrected. What do folks suggest as the proper fix?
> Preventing ".." would be a quick and dirty way to stop path snooping,
> but also blocking all but a set of extensions would be needed.
>
> There are some workarounds:
>
> * use the asset externalization feature so that asset serving is from
> the container or web server rather than the asset service directly
> * use a servlet filter to block everything but .jpg/.gif/.png.
> Interestingly, my clean URL servlet filter on lucenebook.com thwarts
> the security hole.
>
> Howard - what do you see has a fix for this? This warrants a 3.0.3
> release IMO.
>
> Erik
>
>
> On Mar 9, 2005, at 3:58 AM, Danny Angus (JIRA) wrote:
>
>> [
>> http://issues.apache.org/jira/browse/TAPESTRY-278?
>> page=comments#action_60487 ]
>>
>> Danny Angus commented on TAPESTRY-278:
>> --------------------------------------
>>
>> This is a very significant issue which needs addressed as soon as
>> possible.
>>
>>> Tapestry 3.0.2 asset service has security flaw
>>> ----------------------------------------------
>>>
>>> Key: TAPESTRY-278
>>> URL: http://issues.apache.org/jira/browse/TAPESTRY-278
>>> Project: Tapestry
>>> Type: Bug
>>> Components: Framework
>>> Versions: 3.0.2
>>> Environment: Tomcat 5, JDK 1.4
>>> Reporter: Nathan Kopp
>>
>>>
>>> The asset service can be used to view files that should not be
>>> visible. This could expose important resources, including database
>>> passwords and connection information.
>>> The asset service appears to expose any file relative to the
>>> classpath, and you can even use the ".." operator to go backwards,
>>> down into WEB-INF in general.
>>> Here are some examples. They were tested on a demo application
>>> which is often available on the web, but they've been "cleaned," so
>>> they don't point to a real server anymore:
>>> * View the web.xml file:
>>> http://www.someserver.com/tapestry-app/app?
>>> service=asset&sp=S%2F..%2Fweb.xml
>>> * View the tapestry.application file:
>>> http://www.someserver.com/tapestry-app/app?
>>> service=asset&sp=S%2F..%2Ftapestry.application
>>> * View a raw JSP file:
>>> http://www.someserver.com/tapestry-app/app?
>>> service=asset&sp=S%2F..%2F..%2F404.jsp
>>> * Download a few class files that are part of the application:
>>> http://www.someserver.com/tapestry-app/app?
>>> service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FMessageFilter.class
>>> http://www.someserver.com/tapestry-app/app?
>>> service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FBaseEngine.class
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> If you think it was sent incorrectly contact one of the
>> administrators:
>> http://issues.apache.org/jira/secure/Administrators.jspa
>> -
>> If you want more information on JIRA, or have a bug to report see:
>> http://www.atlassian.com/software/jira
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [jira] Commented: (TAPESTRY-278) Tapestry 3.0.2 asset service has security flaw
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
I'm bringing this issue to the e-mail list. Many of us already knew
this existed and it has been discussed here before but I've always used
other techniques to block this hole. I agree its serious and needs to
be corrected. What do folks suggest as the proper fix? Preventing
".." would be a quick and dirty way to stop path snooping, but also
blocking all but a set of extensions would be needed.
There are some workarounds:
* use the asset externalization feature so that asset serving is from
the container or web server rather than the asset service directly
* use a servlet filter to block everything but .jpg/.gif/.png.
Interestingly, my clean URL servlet filter on lucenebook.com thwarts
the security hole.
Howard - what do you see has a fix for this? This warrants a 3.0.3
release IMO.
Erik
On Mar 9, 2005, at 3:58 AM, Danny Angus (JIRA) wrote:
> [
> http://issues.apache.org/jira/browse/TAPESTRY-278?
> page=comments#action_60487 ]
>
> Danny Angus commented on TAPESTRY-278:
> --------------------------------------
>
> This is a very significant issue which needs addressed as soon as
> possible.
>
>> Tapestry 3.0.2 asset service has security flaw
>> ----------------------------------------------
>>
>> Key: TAPESTRY-278
>> URL: http://issues.apache.org/jira/browse/TAPESTRY-278
>> Project: Tapestry
>> Type: Bug
>> Components: Framework
>> Versions: 3.0.2
>> Environment: Tomcat 5, JDK 1.4
>> Reporter: Nathan Kopp
>
>>
>> The asset service can be used to view files that should not be
>> visible. This could expose important resources, including database
>> passwords and connection information.
>> The asset service appears to expose any file relative to the
>> classpath, and you can even use the ".." operator to go backwards,
>> down into WEB-INF in general.
>> Here are some examples. They were tested on a demo application which
>> is often available on the web, but they've been "cleaned," so they
>> don't point to a real server anymore:
>> * View the web.xml file:
>> http://www.someserver.com/tapestry-app/app?
>> service=asset&sp=S%2F..%2Fweb.xml
>> * View the tapestry.application file:
>> http://www.someserver.com/tapestry-app/app?
>> service=asset&sp=S%2F..%2Ftapestry.application
>> * View a raw JSP file:
>> http://www.someserver.com/tapestry-app/app?
>> service=asset&sp=S%2F..%2F..%2F404.jsp
>> * Download a few class files that are part of the application:
>> http://www.someserver.com/tapestry-app/app?
>> service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FMessageFilter.class
>> http://www.someserver.com/tapestry-app/app?
>> service=asset&sp=S%2Forg%2Fappfuse%2Fweb%2FBaseEngine.class
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> http://issues.apache.org/jira/secure/Administrators.jspa
> -
> If you want more information on JIRA, or have a bug to report see:
> http://www.atlassian.com/software/jira
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org