Thanks for the update, it comes so quickly :)
Hope the devtests can pass soon.
thanks
Anissa.
Justin Lee wrote:
> We released a new grizzly release with this fix. Ryan is working on
> integrating it into glassfish but is having some issues with the
> devtest run last I heard. I know, personally, when I run the
> devtests, I get timeouts on start up after running most of the tests.
> The tests try to restart the server and the server is never heard from
> again.
>
> On 6/20/10 6:18 PM, Anissa Lam wrote:
>>
>> Hi Justin /Oleksiy,
>>
>> I would like to know whats the plan for integrating the version of
>> Grizzly that has this issue fixed.
>> According to Justin's comment, the issue was fixed on 6/10. GUI has
>> been waiting for the integration and currently the JDBC resources
>> screen is broken. I really hope that the integration can happen for
>> MS2 build, otherwise, a very common and heavily used
>> functionality in GUI will be broken for MS2.
>>
>> thanks
>> Anissa.
>>
>> Jason Lee wrote:
>>> Issue filed (12116). Thanks.
>>>
>>> On 6/3/10 10:00 AM, Justin Lee wrote:
>>>> I'm currently adding a new attribute to network-listener so file an
>>>> issue for this and assign it to me.
>>>>
>>>> On 6/3/10 10:36 AM, Oleksiy Stashok wrote:
>>>>> If there will be no objections regarding the actual idea of having
>>>>> allowEncodedSlash configurable per <http> protocol, I think we can
>>>>> have that implemented very quickly like today/tomorrow.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> WBR,
>>>>> Alexey.
>>>>>
>>>>> On Jun 3, 2010, at 16:22 , Jason Lee wrote:
>>>>>
>>>>>> That works for me. Hardcoding UDecoder(true) was mostly for PoC
>>>>>> purposes.
>>>>>>
>>>>>> Is everyone OK with the http protocol configuration change? If
>>>>>> so, who will implement that and when can it be done. I think,
>>>>>> for now, I can continue what I'm working on without this change
>>>>>> (which depends on the integration of a new version of Grizzly
>>>>>> anyway), but we'll need that fairly quickly, as tests will fail
>>>>>> without it, which we must have for our MS2 commitment.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> On 6/3/10 4:01 AM, Oleksiy Stashok wrote:
>>>>>>>
>>>>>>>
>>>>>>>> QL is not good enough. You may like to run web devtest in this
>>>>>>>> case.
>>>>>>>>
>>>>>>>> We may like to consider whether we should UDecoder initialized
>>>>>>>> depending on the connector
>>>>>>>> rather than it is fixed ("true") all the time.
>>>>>>> Agree. Because if we will just apply
>>>>>>>
>>>>>>>>> - private final UDecoder urlDecoder = new UDecoder();
>>>>>>>>> + private final UDecoder urlDecoder = new UDecoder(true);
>>>>>>>
>>>>>>> we will enable slashesEncoding for *all* listeners, not just admin.
>>>>>>> I like the idea to introduce "allowEncodedSlash" (or to be
>>>>>>> consistent "encodedSlashEnabled") attribute per
>>>>>>> network-listener, or better per <http> protocol.
>>>>>>> Here is the snippet how network config looks like [1], where we
>>>>>>> have <http> protocol description for each network listener. We
>>>>>>> can introduce additional <http> element's attribute
>>>>>>> "allowEncodedSlash", which will be false by default. This way we
>>>>>>> will have allowEncodedSlash parameter per listener.
>>>>>>>
>>>>>>> Finally <http> protocol description for the admin listener will
>>>>>>> look like:
>>>>>>>
>>>>>>> <protocol name="admin-listener">
>>>>>>> <http default-virtual-server="__asadmin" max-connections="250"
>>>>>>> allowEncodedSlash="true">
>>>>>>> <file-cache />
>>>>>>> </http>
>>>>>>> </protocol>
>>>>>>>
>>>>>>> WBR,
>>>>>>> Alexey.
>>>>>>>
>>>>>>> [1]
>>>>>>> <network-config>
>>>>>>> <protocols>
>>>>>>> <protocol name="http-listener-1">
>>>>>>> <http default-virtual-server="server">
>>>>>>> <file-cache />
>>>>>>> </http>
>>>>>>> </protocol>
>>>>>>> <protocol security-enabled="true" name="http-listener-2">
>>>>>>> <http default-virtual-server="server">
>>>>>>> <file-cache />
>>>>>>> </http>
>>>>>>> <ssl ssl3-enabled="false" cert-nickname="s1as" />
>>>>>>> </protocol>
>>>>>>> <protocol name="admin-listener">
>>>>>>> <http default-virtual-server="__asadmin" max-connections="250">
>>>>>>> <file-cache />
>>>>>>> </http>
>>>>>>> </protocol>
>>>>>>> </protocols>
>>>>>>> <network-listeners>
>>>>>>> <network-listener port="${HTTP_LISTENER_PORT}"
>>>>>>> protocol="http-listener-1" transport="tcp"
>>>>>>> name="http-listener-1" thread-pool="http-thread-pool" />
>>>>>>> <network-listener port="${HTTP_SSL_LISTENER_PORT}"
>>>>>>> protocol="http-listener-2" transport="tcp"
>>>>>>> name="http-listener-2" thread-pool="http-thread-pool" />
>>>>>>> <network-listener port="${ASADMIN_LISTENER_PORT}"
>>>>>>> protocol="admin-listener" transport="tcp" name="admin-listener"
>>>>>>> thread-pool="http-thread-pool" />
>>>>>>> </network-listeners>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Shing Wai Chan
>>>>>>>>
>>>>>>>> On 6/2/10 12:43 PM, Jason Lee wrote:
>>>>>>>>>
>>>>>>>>> On 6/2/10 11:59 AM, Abhijit Kumar wrote:
>>>>>>>>>>
>>>>>>>>>> I have to jump in here. The vulnerability is around being
>>>>>>>>>> able to traverse outside of the so called "document root" of
>>>>>>>>>> the server. Using an encoded URL to get to a file under
>>>>>>>>>> "document root" is not a vulnerability.
>>>>>>>>>>
>>>>>>>>>> IMHO, the answer is fairly simple (and sorry if this was
>>>>>>>>>> already discussed). Grizzly should implement a feature to
>>>>>>>>>> allow configuration of this feature per connector. Admin
>>>>>>>>>> connector (port 4848) should be configured to allow %2F and
>>>>>>>>>> all the applications running there should make sure that
>>>>>>>>>> combination of encoded ".." and "/" can not be used to get to
>>>>>>>>>> unauthorized areas of the server.
>>>>>>>>> I have a status report on two approaches. The first approach
>>>>>>>>> -- disable decoding in ContainerMapper and pushing it to the
>>>>>>>>> Adapter -- works, it seems. It does, at least for the
>>>>>>>>> RestAdapter, and QuickLook didn't seem to be bothered by it.
>>>>>>>>> I'm a little worried, though, that it might break something
>>>>>>>>> else that's not covered by the QL tests.
>>>>>>>>>
>>>>>>>>> The second approach, allowing encoded slashes for EVERY
>>>>>>>>> Adapter on 4848, also seems to work. The diff for that is
>>>>>>>>> pretty simple:
>>>>>>>>>
>>>>>>>>> Index:
>>>>>>>>> kernel/src/main/java/com/sun/enterprise/v3/services/impl/ContainerMapper.java
>>>>>>>>>
>>>>>>>>> ===================================================================
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>> kernel/src/main/java/com/sun/enterprise/v3/services/impl/ContainerMapper.java
>>>>>>>>> (revision 37388)
>>>>>>>>> +++
>>>>>>>>> kernel/src/main/java/com/sun/enterprise/v3/services/impl/ContainerMapper.java
>>>>>>>>> (working copy)
>>>>>>>>> @@ -81,7 +81,7 @@
>>>>>>>>> private Mapper mapper;
>>>>>>>>> private GrizzlyEmbeddedHttp grizzlyEmbeddedHttp;
>>>>>>>>> private String defaultHostName = "server";
>>>>>>>>> - private final UDecoder urlDecoder = new UDecoder();
>>>>>>>>> + private final UDecoder urlDecoder = new UDecoder(true);
>>>>>>>>> private final Habitat habitat;
>>>>>>>>> private final GrizzlyService grizzlyService;
>>>>>>>>> protected final static int MAPPING_DATA = 12;
>>>>>>>>>
>>>>>>>>> Once I updated the jar in my GF instance, URLs like this now
>>>>>>>>> work:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://localhost:4848/management/domain/resources/admin-object-resource/jndi%2Ffoo
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> URLs like this, though, do not:
>>>>>>>>>
>>>>>>>>> http://localhost:4848/management%2F..%2Fmonitoring/domain/server
>>>>>>>>> http://localhost:4848/management/..%2Fmonitoring/domain/server
>>>>>>>>> http://localhost:4848/management%2F../monitoring/domain/server
>>>>>>>>>
>>>>>>>>> For the record, this does:
>>>>>>>>>
>>>>>>>>> http://localhost:4848/management/../monitoring/domain/server
>>>>>>>>>
>>>>>>>>> I'm not sure if that's a problem or not.
>>>>>>>>>
>>>>>>>>> Another approach would be to get the Adapter before decoding,
>>>>>>>>> create a new UDecoder on every request (new
>>>>>>>>> UDecoder(adapter.isAllowEncodedSlash()), then decode the URL.
>>>>>>>>> While that shrinks any potential attack surface, it may also
>>>>>>>>> run afoul of the possibility of the multibyte characters Shing
>>>>>>>>> Wai mentioned, which may or may not be an issue with the GF
>>>>>>>>> administration port.
>>>>>>>>>
>>>>>>>>> Now, having said all of that, we really need to make a
>>>>>>>>> decision so this can move on. Aesthetically, single encoding
>>>>>>>>> looks better, and it's certainly more intuitive to the end
>>>>>>>>> user. In case this hasn't been clear, though, I'm a bit
>>>>>>>>> nervous making changes like this due to unintended
>>>>>>>>> consequences. I've tried to exploit this change to get to
>>>>>>>>> things I'm not supposed to, but haven't been able to yet, for
>>>>>>>>> what it's worth.
>>>>>>>>>
>>>>>>>>> The double encoding approach, while slightly uglier, also
>>>>>>>>> works and seems to be free of any security concerns. I also
>>>>>>>>> have it implemented already. :P
>>>>>>>>>
>>>>>>>>> I don't have a strong preference either way, so I'm perfectly
>>>>>>>>> content with adopting whatever the general consensus here is,
>>>>>>>>> which I'd like to determine as quickly as we can, as we've
>>>>>>>>> spent a lot of time on this already, and this issue is holding
>>>>>>>>> up MS2 deliverables.
>>>>>>>>>
>>>>>>>>> Let the voting commence. :)
>>>>>>>>> --
>>>>>>>>> Jason Lee
>>>>>>>>> Senior Member of Technical Staff
>>>>>>>>> GlassFish Administration Console
>>>>>>>>>
>>>>>>>>> Oracle Corporation
>>>>>>>>> Phone +1 405-216-3193
>>>>>>>>> Blog http://blogs.steeplesoft.com
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Jason Lee
>>>>>> Senior Member of Technical Staff
>>>>>> GlassFish Administration Console
>>>>>>
>>>>>> Oracle Corporation
>>>>>> Phone +1 405-216-3193
>>>>>> Blog http://blogs.steeplesoft.com
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>>
>>>
>>>