My general comments follow Bill's concerns about accessing resources
that the "client" itself would normally have access to or potentially
use the "credentials" of the server to access the resource on behalf of
the client.
Beyond that I think there are a few other items to consider:
A) An option to disable the deployuri command completely should the
administrator be concerned
B) An option to limit the URI types that would be allowed
C) Allow for specification of a "sandbox" area use as the download
location to better control permissions, ownership, quotas, disk space, etc.
D) Allow for the possibility to include hooks for virus scanners or
other intrusion detection software
Thanks, -Craig
-------- Original Message --------
Subject: Re: request asarch review for deploy command enhancement in
GlassFish
From: 吕宋平 <lvsongping_at_gmail.com>
To: Bill Shannon <bill.shannon_at_oracle.com>
CC: hong.hz.zhang_at_oracle.com, dev_at_glassfish.java.net
Date: Thursday, May 23, 2013 6:45:51 AM
> Hi, Bill:
>
> 2013/5/23 Bill Shannon <bill.shannon_at_oracle.com
> <mailto:bill.shannon_at_oracle.com>>
>
> 吕宋平 wrote on 05/22/13 01:18:
>>
>> Hi, Bill:
>>
>> Cc: asarch_ww members, Security team:
>>
>> Yes, the one pager which have been approved to the wiki didn't
>> take care such security problem. The change can cause the server
>> to access files and network resources that the administrator
>> might not be able to access directly. But I think this security
>> issue is only happen in the file:// syntax.
>>
>> I think both of the administrator and server can access the
>> source file and network resource when it comes to the http://
>> syntax and ftp:// syntax, so I think it is no need to take care
>> the security into consideration when it comes to these situation.
>>
> The ability to access it might depend on what IP address is being
> used, which will be different between the client and the server.
>
> You also have to be sure that the server isn't going to use any
> HTTP authentication when accessing the resource since the client
> might not have permission to use that authentication information
> stored on the server.
> Yes, I will. I think the operation about download the remote
> resource will be based on the situation that the client have the
> permission to access it without any authentication information
> stored on the server. Because it's hard for the glassfish client
> to process such a situation.
>>
>> [For Example]
>>
>> A: glassfish server
>>
>> B: glassfish server
>>
>> C: ftp server
>>
>> D: http server
>>
>> (1)Deploy the application from the machine B(Regard A as a admin
>> client side, Regard B as a server side)
>>
>> Execute the command line on the machine A as “asadmin deployuri
>> --host host_address_B file:///etc/appname”, It's true that
>> administrator A can't access the application exist on the machine
>> B, but the application will be deployed to the B through this
>> command, the administrator of A only know the application name
>> but don't know what exist in the application. I don't think it
>> will affect so much to the security.
>>
>> (2)Deploy the application from the machine C
>>
>> Execute the command line on the machine A as “asadmin
>> deployuriftp://username:password@host_C:21/appname
>> <ftp://username:password@host_c/appname>”, I think both of the
>> administrator and server side on the machine A can access the
>> application exist on the ftp server C. I think it's no need to
>> take the security into consideration here because both of the
>> administrator and server can access the source file.
>>
>> (3)Deploy the application from the machine D
>>
>> Execute the command line on the machine A as “asadmin
>> deployurihttp://host_address_D/appname
>> <http://host_address_d/appname>”, I think both of the
>> administrator and server side on the machine A can access the
>> application exist on the http server D. I think it's no need to
>> take the security into consideration here because both of the
>> administrator and server can access the source file.
>>
>> >Perhaps I'm being paranoid but I'd like to see some discussion about the security implications
>> of being able to tell >the server to access resources that you
>> might not be able to access directly. Certainly the check for
>> filename >extensions will help, but you still need to be sure to
>> handle cases such as "file:///etc/passwd?name=foo.ear".
>> I'm not sure about the file:// syntax
>> "file:///etc/passwd?name=foo.ear". Could you clarify about this?
> If you just look at the end of the string to see if it ends with
> ".ear", you'll think that name is ok. But it's not. It actually
> accesses the /etc/passwd file.
> Ok, I got it!
>
>> I don't think the change will affect the security too much. So I
>> hopeyou and the security team's will list more questions and
>> discussion here.
> Yes, I really want to hear more from our security experts.
> Ok, let's wait for the security to list some suggestion about this!
>
> Thanks a lot!
> -Jeremy