Re: AW: Possible security bug in handling digest password

[Mir Shafiqul Islam]

Werner, I also will echo what Andy said, I think the following line in 
WSSConfig.java (line 45) file should be set to false by default so that 
people do not run into trouble with non compliant messages.

protected boolean processNonCompliantMessages = true;
However, the problem still exists if someone has the option set to true 
(knowingly). The supplied (non compliant) message does not get processed 
as it should be and exposes the security hole I mentioned in previous mail.

Thanks a lot for the clarification.
Mir
Andy Kriger wrote:
Is this something that will be changed in the CVS-kept codebase? I
think that WSS4J needs to make available code that is secure out of
the box (without requiring code changes or config changes).
On 4/21/05, Dittmann Werner <[EMAIL PROTECTED]> wrote:
 

Mir,
sorry, I didn't read your e-mail carefully. WSS4J can be
configured to support this behaviour using parameters
in WSSConfig.java. Currently the parameter
"processNonCompliantMessages" is set to true, meaning that
WSS4J processes non-compliant messages (messages that
do use a match of the various OASIS WSS namespaces). This
was done to support a simple migration from the various draft
specifications to the agreed standard.
If you set this parameter to false (and recompile the whole
stuff - unfortunatly we didn't yet implement a way do do
it during runtime) then WSS4J is restrictive in the sense you
mentioned.
Regards,
Werner
   

-----Urspr�ngliche Nachricht-----
Von: Mir Shafiqul Islam [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 20. April 2005 17:53
An: Dittmann Werner
Cc: fx-dev@ws.apache.org
Betreff: Re: AW: Possible security bug in handling digest password
Hi Werner, you are absolutely right in your assessment of mixing the
name spaces and not sticking to one single one. However, an attacker
would not mind doing it and mix and match name spaces to access the
service without being authorized. And that is my point, if
the xml sent
does not adhere to a specification or mix and match and wss4j can not
properly detect the required element (in this case the digest
password)
wss4j should throw up its hands in the air and not let anyone
in. Right
now it just silently lets the invoker pass through and invoke
the actual
service (ping1.py).
Thanks
Mir
Dittmann Werner wrote:
     

Hir,
loking at your examples I found that you mix some "standard"
levels of the WS specification (yes, there were some draft
standards, the first implementation of WSS4J implemented a
draft, later we changed to the agreed standard - this is why
we intoduced the "backward" compatibility mode, the various
string are defined in WSConstants, by default we use the
OASIS_1_= setup).
The ping2.py is the example that uses the right URI for the
password type, however the napespace definition for wsu
is not correct. It should read as:
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssec
       

urity-utility-1.0.xsd
     

if you use the agreed OASIS 1.0 specification (if you refer
to the original OASIS docs pls also look at the errata when
looking up the correct namespace defintions).
Because of the wrong wsu namespace WSS4J cannot find an element
that is required for PasswordDigest (wsu:Created).
Regards,
Werner

       

-----Urspr�ngliche Nachricht-----
Von: Mir Shafiqul Islam [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 19. April 2005 21:46
An: fx-dev@ws.apache.org
Betreff: Possible security bug in handling digest password
I am new to wss4j and ws-security in general. So I maybe missing
something obvious.
I have axis 1.2 RC3 along with latest wss4j code from cvs. I have a
simple service setup with my own password call back handler and
everything works as expected from java environment. However, while
testing interoperability with some simple python scripts I
         

ran into a
     

behavior that I can at best call a security hole.
Here is the scenario. If the password Type is specified as
"wsse:PasswordDigest" (compliant to older specification) the
WSDoAllReceiver class never detects the password as
         

legitimate digest
     

password. The type is compared against fixed constant value
specified in
WSConstants.PASSWORD_DIGEST
(http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-usern
         

ame-token-profile-1.0#PasswordDigest).
Since the password type supplied is non compliant (or
       

unknown) to the
     

Type specification should not wss4j throw some sort of
       

exception? The
     

user is allowed to invoke the web service method as if he was fully
authenticated. This can be easily reproduced with the
       

attached python
     

scripts. Just create a simple echo/ping service with axis and wss4j
ping1.py : Does not authenticate using password call back
       

class and lets
     

user invoke method
ping2.py : Does the right thing and invokes appropriate
       

password call
     

back class
server.config.xml : My service deployer file
ping1.output.txt: Packet captured via ethereal. Never
       

authenticated the
     

user but invoked the ws method successfully
ping2.output.txt: Packet captured via ethereal. Failed to
       

authenticate
     

the user so displayed proper error message
Thanks!
Mir