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