Security hole in Axis2 1.4 + Rampart 1.4

[Nunny]

Hi,
   There are few issues with Axis2 1.4 / Rampart 1.4 with the new policy configuration. The new policy configuration which allows us to apply policies to binding hierarchy is a great feature when in comes to ws security policy configuration. It allows security policies to be attached to the correct attachment points. But there are few issues that need to be fixed in Axis2 1.4. I will list them below.
    1.) If we configure security using new configuration, service can be accessed without security.
         In Axis2 1.4, a service is exposed in two EPRs (consider SOAP 1.1 binding).
           eg.
               http://localhost:8080/axis2/services/SecureService.SecureServiceHttpSoap11Endpoint
               http://localhost:8080/axis2/services/SecureService
          But if we you set the policies using the new configuration, if you do a web service call to the older EPR, you can access the service without any security even though it is secured using the binding hierarchy. This happens because if we call the old EPR, it is not dispatched to a binding. But this leaves the service vulnerable. I think we should dispatch to one of the bindings may be using soap envelope version if we have only one binding with that soap version. We should have a way to dispatch messages which comes to old EPR to one of the bindings else we should have an option to disable that EPR.
 
    2.) In the out flow, policies are not set correctly in the binding message.
          This is fixed in the trunk but this bug is there in Axis2 1.4.

   So the option we have is to configure security using the old configuration. But then the problem is policies are attached to the port type which is the correct way to do if we have policies using <service>,<operation><message> tags. But this makes Axis2 not interoperable as security policies should be attached to binding hierarchy according WS Security policy specification. Ideally we should always use the new configuration to apply security. And code generation also doesn't work correctly when the policies attached to the port type (polices are not correctly attached to the stub).
 
   So I think it would be great if can consider a Axis2 1.4.1 with these things fixed.   

thanks,
nandana   

[Keithgchapman]

+1 for a 1.4.1. There were some other issues that I noticed in 1.4 as well, some of these are already fixed in trunk.

https://issues.apache.org/jira/browse/AXIS2-3819
https://issues.apache.org/jira/browse/AXIS2-3859
https://issues.apache.org/jira/browse/AXIS2-3867
https://issues.apache.org/jira/browse/AXIS2-3877

Thanks,
Keith.

On Mon, Jun 30, 2008 at 8:59 PM, Nandana Mihindukulasooriya <nandana.cse@...> wrote:

Hi,
   There are few issues with Axis2 1.4 / Rampart 1.4 with the new policy configuration. The new policy configuration which allows us to apply policies to binding hierarchy is a great feature when in comes to ws security policy configuration. It allows security policies to be attached to the correct attachment points. But there are few issues that need to be fixed in Axis2 1.4. I will list them below.
    1.) If we configure security using new configuration, service can be accessed without security.
         In Axis2 1.4, a service is exposed in two EPRs (consider SOAP 1.1 binding).
           eg.
               http://localhost:8080/axis2/services/SecureService.SecureServiceHttpSoap11Endpoint
               http://localhost:8080/axis2/services/SecureService
          But if we you set the policies using the new configuration, if you do a web service call to the older EPR, you can access the service without any security even though it is secured using the binding hierarchy. This happens because if we call the old EPR, it is not dispatched to a binding. But this leaves the service vulnerable. I think we should dispatch to one of the bindings may be using soap envelope version if we have only one binding with that soap version. We should have a way to dispatch messages which comes to old EPR to one of the bindings else we should have an option to disable that EPR.
 
    2.) In the out flow, policies are not set correctly in the binding message.
          This is fixed in the trunk but this bug is there in Axis2 1.4.

   So the option we have is to configure security using the old configuration. But then the problem is policies are attached to the port type which is the correct way to do if we have policies using <service>,<operation><message> tags. But this makes Axis2 not interoperable as security policies should be attached to binding hierarchy according WS Security policy specification. Ideally we should always use the new configuration to apply security. And code generation also doesn't work correctly when the policies attached to the port type (polices are not correctly attached to the stub).
 
   So I think it would be great if can consider a Axis2 1.4.1 with these things fixed.   

thanks,
nandana   

--
Keith Chapman
Senior Software Engineer
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/

blog: http://www.keith-chapman.org

[David Illsley-3]

Ouch. That's really not good.

+1 for a 1.4.1

David

On Mon, Jun 30, 2008 at 4:29 PM, Nandana Mihindukulasooriya
<nandana.cse@...> wrote:

> Hi,
>    There are few issues with Axis2 1.4 / Rampart 1.4 with the new policy
> configuration. The new policy configuration which allows us to apply
> policies to binding hierarchy is a great feature when in comes to ws
> security policy configuration. It allows security policies to be attached to
> the correct attachment points. But there are few issues that need to be
> fixed in Axis2 1.4. I will list them below.
>     1.) If we configure security using new configuration, service can be
> accessed without security.
>          In Axis2 1.4, a service is exposed in two EPRs (consider SOAP 1.1
> binding).
>            eg.
>
> http://localhost:8080/axis2/services/SecureService.SecureServiceHttpSoap11Endpoint
>                http://localhost:8080/axis2/services/SecureService
>           But if we you set the policies using the new configuration, if you
> do a web service call to the older EPR, you can access the service without
> any security even though it is secured using the binding hierarchy. This
> happens because if we call the old EPR, it is not dispatched to a binding.
> But this leaves the service vulnerable. I think we should dispatch to one of
> the bindings may be using soap envelope version if we have only one binding
> with that soap version. We should have a way to dispatch messages which
> comes to old EPR to one of the bindings else we should have an option to
> disable that EPR.
>
>     2.) In the out flow, policies are not set correctly in the binding
> message.
>           This is fixed in the trunk but this bug is there in Axis2 1.4.
>
>    So the option we have is to configure security using the old
> configuration. But then the problem is policies are attached to the port
> type which is the correct way to do if we have policies using
> <service>,<operation><message> tags. But this makes Axis2 not interoperable
> as security policies should be attached to binding hierarchy according WS
> Security policy specification. Ideally we should always use the new
> configuration to apply security. And code generation also doesn't work
> correctly when the policies attached to the port type (polices are not
> correctly attached to the stub).
>
>    So I think it would be great if can consider a Axis2 1.4.1 with these
> things fixed.
>
> thanks,
> nandana

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@...
For additional commands, e-mail: axis-dev-help@...

[Sanka Samaranayake-3]

Hi,

For the users who is already using 1.4 version, the workaround would be to define policies in services.xml without using <wsa:PolicyAttachment>. Then the problem is that those policies will appear in <wsdl:PortType> which is not correct but security will apply for both format of service URLs.

Hence +1 for fixing that issue and do 1.4.1 release.

Thanks,
Sanka

On Mon, Jun 30, 2008 at 8:59 PM, Nandana Mihindukulasooriya <nandana.cse@...> wrote:

Hi,
   There are few issues with Axis2 1.4 / Rampart 1.4 with the new policy configuration. The new policy configuration which allows us to apply policies to binding hierarchy is a great feature when in comes to ws security policy configuration. It allows security policies to be attached to the correct attachment points. But there are few issues that need to be fixed in Axis2 1.4. I will list them below.
    1.) If we configure security using new configuration, service can be accessed without security.
         In Axis2 1.4, a service is exposed in two EPRs (consider SOAP 1.1 binding).
           eg.
               http://localhost:8080/axis2/services/SecureService.SecureServiceHttpSoap11Endpoint
               http://localhost:8080/axis2/services/SecureService
          But if we you set the policies using the new configuration, if you do a web service call to the older EPR, you can access the service without any security even though it is secured using the binding hierarchy. This happens because if we call the old EPR, it is not dispatched to a binding. But this leaves the service vulnerable. I think we should dispatch to one of the bindings may be using soap envelope version if we have only one binding with that soap version. We should have a way to dispatch messages which comes to old EPR to one of the bindings else we should have an option to disable that EPR.
 
    2.) In the out flow, policies are not set correctly in the binding message.
          This is fixed in the trunk but this bug is there in Axis2 1.4.

   So the option we have is to configure security using the old configuration. But then the problem is policies are attached to the port type which is the correct way to do if we have policies using <service>,<operation><message> tags. But this makes Axis2 not interoperable as security policies should be attached to binding hierarchy according WS Security policy specification. Ideally we should always use the new configuration to apply security. And code generation also doesn't work correctly when the policies attached to the port type (polices are not correctly attached to the stub).
 
   So I think it would be great if can consider a Axis2 1.4.1 with these things fixed.   

thanks,
nandana   

--
Sanka Samaranayake
WSO2 Inc.

http://sankas.blogspot.com/
http://www.wso2.org/

[dims]

IMHO, The logic is the same as for blockers. If there is a work
around, it's not a blocker. So i am +0 on a 1.4.1 since there is a
work around that can be documented.

That said, If someone is willing to drive a 1.4.1 as the release
manager, please do go ahead.

thanks,
dims

On Tue, Jul 1, 2008 at 2:48 AM, Sanka Samaranayake <ssanka@...> wrote:

> Hi,
>
> For the users who is already using 1.4 version, the workaround would be to
> define policies in services.xml without using <wsa:PolicyAttachment>. Then
> the problem is that those policies will appear in <wsdl:PortType> which is
> not correct but security will apply for both format of service URLs.
>
> Hence +1 for fixing that issue and do 1.4.1 release.
>
> Thanks,
> Sanka
>
>
> On Mon, Jun 30, 2008 at 8:59 PM, Nandana Mihindukulasooriya
> <nandana.cse@...> wrote:
>>
>> Hi,
>>    There are few issues with Axis2 1.4 / Rampart 1.4 with the new policy
>> configuration. The new policy configuration which allows us to apply
>> policies to binding hierarchy is a great feature when in comes to ws
>> security policy configuration. It allows security policies to be attached to
>> the correct attachment points. But there are few issues that need to be
>> fixed in Axis2 1.4. I will list them below.
>>     1.) If we configure security using new configuration, service can be
>> accessed without security.
>>          In Axis2 1.4, a service is exposed in two EPRs (consider SOAP 1.1
>> binding).
>>            eg.
>>
>> http://localhost:8080/axis2/services/SecureService.SecureServiceHttpSoap11Endpoint
>>                http://localhost:8080/axis2/services/SecureService
>>           But if we you set the policies using the new configuration, if
>> you do a web service call to the older EPR, you can access the service
>> without any security even though it is secured using the binding hierarchy.
>> This happens because if we call the old EPR, it is not dispatched to a
>> binding. But this leaves the service vulnerable. I think we should dispatch
>> to one of the bindings may be using soap envelope version if we have only
>> one binding with that soap version. We should have a way to dispatch
>> messages which comes to old EPR to one of the bindings else we should have
>> an option to disable that EPR.
>>
>>     2.) In the out flow, policies are not set correctly in the binding
>> message.
>>           This is fixed in the trunk but this bug is there in Axis2 1.4.
>>
>>    So the option we have is to configure security using the old
>> configuration. But then the problem is policies are attached to the port
>> type which is the correct way to do if we have policies using
>> <service>,<operation><message> tags. But this makes Axis2 not interoperable
>> as security policies should be attached to binding hierarchy according WS
>> Security policy specification. Ideally we should always use the new
>> configuration to apply security. And code generation also doesn't work
>> correctly when the policies attached to the port type (polices are not
>> correctly attached to the stub).
>>
>>    So I think it would be great if can consider a Axis2 1.4.1 with these
>> things fixed.
>>
>> thanks,
>> nandana
>
>
> --
> Sanka Samaranayake
> WSO2 Inc.
>
> http://sankas.blogspot.com/
> http://www.wso2.org/

--
Davanum Srinivas :: http://davanum.wordpress.com

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@...
For additional commands, e-mail: axis-dev-help@...

[Nunny]

I would like to volunteer to be the release manager for Axis2 1.4.1.

I think we can fix the critical issues in the 1.4 branch (or a 1.4.1 branch ) and do the 1.4.1 release. I don't think doing 1.4.1 from the trunk is the appropriate way as trunk is now java 1.5 and has lot of major changes after Axis2 1.4 . However we can fix any issues that are not already fixed in the trunk at the same time when we fix those in the branch.

Hope this is oky with Axis2 release guidelines.

thanks,
nandana

On Tue, Jul 1, 2008 at 6:39 PM, Davanum Srinivas <davanum@...> wrote:

IMHO, The logic is the same as for blockers. If there is a work
around, it's not a blocker. So i am +0 on a 1.4.1 since there is a
work around that can be documented.

That said, If someone is willing to drive a 1.4.1 as the release
manager, please do go ahead.

thanks,
dims

On Tue, Jul 1, 2008 at 2:48 AM, Sanka Samaranayake <ssanka@...> wrote:
> Hi,
>
> For the users who is already using 1.4 version, the workaround would be to
> define policies in services.xml without using <wsa:PolicyAttachment>. Then
> the problem is that those policies will appear in <wsdl:PortType> which is
> not correct but security will apply for both format of service URLs.
>
> Hence +1 for fixing that issue and do 1.4.1 release.
>
> Thanks,
> Sanka
>
>
> On Mon, Jun 30, 2008 at 8:59 PM, Nandana Mihindukulasooriya
> <nandana.cse@...> wrote:
>>
>> Hi,
>>    There are few issues with Axis2 1.4 / Rampart 1.4 with the new policy
>> configuration. The new policy configuration which allows us to apply
>> policies to binding hierarchy is a great feature when in comes to ws
>> security policy configuration. It allows security policies to be attached to
>> the correct attachment points. But there are few issues that need to be
>> fixed in Axis2 1.4. I will list them below.
>>     1.) If we configure security using new configuration, service can be
>> accessed without security.
>>          In Axis2 1.4, a service is exposed in two EPRs (consider SOAP 1.1
>> binding).
>>            eg.
>>
>> http://localhost:8080/axis2/services/SecureService.SecureServiceHttpSoap11Endpoint
>>                http://localhost:8080/axis2/services/SecureService
>>           But if we you set the policies using the new configuration, if
>> you do a web service call to the older EPR, you can access the service
>> without any security even though it is secured using the binding hierarchy.
>> This happens because if we call the old EPR, it is not dispatched to a
>> binding. But this leaves the service vulnerable. I think we should dispatch
>> to one of the bindings may be using soap envelope version if we have only
>> one binding with that soap version. We should have a way to dispatch
>> messages which comes to old EPR to one of the bindings else we should have
>> an option to disable that EPR.
>>
>>     2.) In the out flow, policies are not set correctly in the binding
>> message.
>>           This is fixed in the trunk but this bug is there in Axis2 1.4.
>>
>>    So the option we have is to configure security using the old
>> configuration. But then the problem is policies are attached to the port
>> type which is the correct way to do if we have policies using
>> <service>,<operation><message> tags. But this makes Axis2 not interoperable
>> as security policies should be attached to binding hierarchy according WS
>> Security policy specification. Ideally we should always use the new
>> configuration to apply security. And code generation also doesn't work
>> correctly when the policies attached to the port type (polices are not
>> correctly attached to the stub).
>>
>>    So I think it would be great if can consider a Axis2 1.4.1 with these
>> things fixed.
>>
>> thanks,
>> nandana
>
>
> --
> Sanka Samaranayake
> WSO2 Inc.
>
> http://sankas.blogspot.com/
> http://www.wso2.org/

--
Davanum Srinivas :: http://davanum.wordpress.com

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@...
For additional commands, e-mail: axis-dev-help@...