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