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