The support glassfish changes are in now. the allowEncodedSlash web
devtest exercises this new code if you need a reference.
On 6/21/10 10:34 AM, Anissa Lam wrote:
>
> Thanks !!
>
> Anissa.
>
> Ryan Lubke wrote:
>> On 6/20/10 3:28 PM, Anissa Lam wrote:
>>>
>>> Thanks for the update, it comes so quickly :)
>>> Hope the devtests can pass soon.
>> Integration was completed yesterday evening. Please let us know if
>> you run into any issues.
>>
>> Thanks,
>> -rl
>>>
>>> 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
>>>>>>>
>>>>>>
>>>>>>
>>