Security issue with GroupWise 6 and LDAP authentication in PostOffice

[Frank Bulk <frnkblk () iname com>]

Issue: Any user can login into any GroupWise 
account.

Environment: GroupWise 6 Post Office using LDAP 
authentication AND security configuration of 
PostOffice leaves LDAP User Name and Password 
fields blank in the Post Office Agent object in 
ConsoleOne. 

Exploit: Run GroupWise as any user 
(either "grpwise /@u-?") OR if you are not NDS 
authenticated, whatever the registry has stored as 
the last person who logged into GroupWise) and 
leave the password blank.  Hit enter a couple of times 
and you will get right into the account.

Details:  TID 10067921 should be posted as it shows 
the steps you need to take to leave LDAP 
authentication on, and not have the password 
problem.  When I spoke to the technician on the 14th 
it was supposed to have been posted, but it hasn't yet.

Fix: 
A.  Novell has developed a workaround to this issue 
in the LDAP spec to prevent GroupWise accounts 
from being accessed without a password. This fix is 
found in the Field Test File FGW62N4.EXE. This can 
be found at support.novell.com and searching for the 
filename.  
Pro: solves problem, retains current password 
functionality.
Con: New code comes with possible stability issues.

B.  Without implementing the new code, the issue 
can be resolved as follows: Fill in the LDAP User 
Name and Password fields in the Post Office Agent 
object in ConsoleOne. The LDAP User Name is the 
eDirectory account that the POA, the Internet Agent, 
and the WebAccess Agent can use to log in to the 
LDAP server in order to authenticate GroupWise 
users. 
Pro: this approach to LDAP authentication is faster 
and requires fewer connections to the LDAP server 
than if each GroupWise user authenticates to the 
LDAP server individually. 
Con: From within GroupWise, users will not be able 
to use grace logins, nor will they be able to change 
their LDAP passwords. 

Technical details (in Novell's words):  This isn't 
technically a bug, but a configuration issue. In 
accordance with the LDAP v3 RFC 2251, an LDAP 
bind in which a username is provided but a password 
is not [ie. blank] is treated as an anonymous bind. 
This means that a bind is granted to users providing 
a username but no password.  The bind granted is an 
anonymous bind but, based on limitations in the 
LDAP spec, most LDAP implementations do not 
provide any indication that the bind is in fact 
anonymous. GroupWise relies on the success or 
failure of a bind to determine whether a users 
username and password is authentic when LDAP 
authentication is being used [if you put LDAP trace on 
you will see that blank password become anonymous 
binds].  The problem is in the RFC, not GroupWise. 
Once we realized that RFC had the hole, we made a 
change in the POA.  This problem only came to our 
attention about 2 weeks ago so it takes time for 
information to get out. 

Remaining question: How come the Padlock fix was 
so heavily advertised (read: spammed) and this 
major hole was open?  Why didn't the FTF make a 
bigger deal of it?