Summary: Specially crafted Server Side Sort crashes directory server or
makes it unresponsive
https://bugzilla.redhat.com/show_bug.cgi?id=472457
[Problem Description]
A test case posted by Andrey Ivanov could cause the directory server
crash. A function to log the server side sorting sort_log_access had a
bug to count the string size to be stored in the buffer. The code meant
if the string length is less than or equal to the static buffer size, it
uses the buffer. If it is longer, it allocates the enough size of space
and use it. This is the sample of the string to log:
SORT -sn;2.16.840.1.113730.3.3.2.18.1.6
-givenName;2.16.840.1.113730.3.3.2.18.1.6 (1944)
The last "(1944)" is a count of candidates. The length was missing in
the calculation for the string size.
[Proposed patch]
Created an attachment (id=324508) [details]
cvs diff ldap/servers/slapd/back-ldbm/sort.c
The cause of the problem was a buffer overflow.
The length of the 2 sort specs "-sn;2.16.840.1.113730.3.3.2.18.1.6
-givenName;2.16.840.1.113730.3.3.2.18.1.6 " is just about the prepared buffer
size, which is unfortunate since there is no space for the candidate size,
e.g., "(1944)" being added later. By adding the "(1944)" to the static buffer,
it caused buffer overflow and crashed your server.
The code to check the length of the candidate size before calculating the buffer size is added.
Thanks,
--noriko
https://bugzilla.redhat.com/show_bug.cgi?id=216522
Resolves: bug 216522
Bug Description: The global password policy was always being used for
password changes made with the password modify extended operation,
even if a local policy was defined for the user/subtree.
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: The password modify extended operation ends up using an
internal modify operation to perform the actual change. Unfortunately,
we don't look for local password policies for internal operations.
When choosing between the global and local password policies,
we should always choose the local policy if one applies, regardless of the
operation being internal or not. This fix simply makes us check for local
policies for internal operations.
A change was needed with where we fetch the policy when we are returning a
result. We used to always fetch a policy, even though we only needed
it when
we were dealing with an error 49. This was causing us to infinitely
recurse
with the above change for fetching local policies for internal
operations. The
password policy code would perform an internal search for the local policy
container, which would trigger the policy to be looked up again when
we return
the result for the internal operation. Since we only need to fetch
the policy
at result time for an error 49, I changed the code to only fetch the
policy in
this case. This case will never be true for an internal operation
since we
don't need to provide a bind DN or password.
Platforms tested: Fedora 9 i686
Flag Day: no
Doc impact: no
https://bugzilla.redhat.com/attachment.cgi?id=324353&action=diff
https://bugzilla.redhat.com/show_bug.cgi?id=469261
Resolves: bug 469261
Bug Description: Support server-to-server SASL - console replication changes
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: This adds support for starttls, gssapi, and digest to
the console for setting up replication agreements.
1) Instead of a checkbox for use ssl, I added 3 radio buttons - no ssl,
regular ldaps, starttls - note: active directory supports starttls
2) To the ssl auth and simple auth radio buttons, I added gssapi and
digest. The way the logic works is that gssapi is only allowed when
using regular ldap, digest and simple bind are allowed always, ssl auth
is only allowed with one of the ssl options. gssapi allows an empty
bind dn and password, but digest and simple require a bind dn and
password. NOTE: we do not support anything other than simple bind with
active directory in the GUI
I also changed the wording a little bit, and added tool tips (which will
hopefully not be too annoying)
I did not add additional checking e.g. the console cannot verify that
kerberos is set up properly
Platforms tested: RHEL5
Flag Day: no
Doc impact: oh yes
https://bugzilla.redhat.com/attachment.cgi?id=324349&action=diff
https://bugzilla.redhat.com/show_bug.cgi?id=450046
esolves: bug 450046
Bug Description: The semaphore used by the changelog can be left around
if the server doesn't exit cleanly. If the value happens to be at 0
when this happens, the server will be unable to write to the changelog
the next time it is started.
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: This fix makes the changelog code attempt to create the
semaphore with exclusive access. If this fails due to the semaphore
being left around from a previous unclean exit of the server, we delete
the semaphore and re-create it.
Platforms tested: Fedora 8 x86_64
Flag Day: no
Doc impact: no
https://bugzilla.redhat.com/attachment.cgi?id=323522&action=diff
https://bugzilla.redhat.com/show_bug.cgi?id=470918
Resolves: bug 470918
Bug Description: The replica_set_updatedn() checks the type of modify
operation that
it is dealing with by checking if specific bits are set when the
replica update DN
attribute is being modified. The problem is that the value of
LDAP_MOD_ADD is 0,
so you can't use a simple bit check.
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: The fix is to check the value of the modify operation
type instead
of doing a simple bit check. We need to be careful to exclude the bit
flag for
LDAP_MOD_BVALUES since it could be set along with any of the modify op
types.
Platforms tested: Fedora 8
Flag Day: no
Doc impact: no
https://bugzilla.redhat.com/attachment.cgi?id=323481&action=diff
> Date: Mon, 10 Nov 2008 13:35:27 -0700
> From: Rich Megginson<rmeggins(a)redhat.com>
> https://bugzilla.redhat.com/show_bug.cgi?id=469261
> Resolves: bug 469261
> Bug Description: Support server-to-server SASL - part 4 - pta, winsync
> Reviewed by: ???
> Files: see diff
> Branch: HEAD
> Fix Description: Allow pass through auth (PTA) to use starttls. PTA
> uses the old style argv config params, so I just added an optional
> starttls (0, 1) to the end of the list, since there is currently no way
> to encode the startTLS extop in the LDAP URL.
I recently added support to OpenLDAP's libldap for specifying StartTLS as an
LDAP URL extension. It seems this was discussed on the IETF LDAPext group some
time ago and then it died. Perhaps if you add a request to the discussion we
can get this resurrected and standardized. IMO there's an obvious need for this.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
https://bugzilla.redhat.com/show_bug.cgi?id=469261
Resolves: bug 469261
Bug Description: Support server-to-server SASL - part 4 - pta, winsync
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: Allow pass through auth (PTA) to use starttls. PTA
uses the old style argv config params, so I just added an optional
starttls (0, 1) to the end of the list, since there is currently no way
to encode the startTLS extop in the LDAP URL. NOTE: adding support for
true pass through auth for sasl or external cert auth will require a lot
of work - not sure it's worth it - anyone other than console users can
use chaining backend instead.
For windows sync, I just ported the same slapi_ldap_init/slapi_ldap_bind
changes made to regular replication to the windows specific code. The
Windows code still needs the do_simple_bind function to check the
windows password, but it is not used for server to server bind anymore.
NOTE: Windows does support startTLS, but I did not test the SASL
mechanisms with Windows.
Platforms tested: Fedora 9
Flag Day: no
Doc impact: yes
https://bugzilla.redhat.com/attachment.cgi?id=323115&action=diff
https://bugzilla.redhat.com/show_bug.cgi?id=469261
Resolves: bug 469261
Bug Description: Support server-to-server SASL - part 3 - dna plugin
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: Changed the DNA code to use the new
slapi_ldap_init/slapi_ldap_bind code. Also changed the code to get the
port number to use from the replication agreement. Added some more
replication internal code knowledge to the DNA code (unfortunately).
Platforms tested: Fedora 9
Flag Day: no
Doc impact: yes
https://bugzilla.redhat.com/attachment.cgi?id=322915&action=diff
https://bugzilla.redhat.com/show_bug.cgi?id=469261
Resolves: bug 469261
Bug Description: Support server-to-server SASL - kerberos improvements
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: I made several improvements to the kerberos code at
Simo's suggestion
First look for the principal in the ccache. If not found, use the
username if it does not look like a DN. If still not found, construct a
principal using the krb5_sname_to_principal() function to construct
"ldap/fqdn@REALM".
Next, see if the credentials for this principal are still valid. In
order to grab the credentials from the ccache, I needed to construct the
server principal, which in this case is the TGS service principal (e.g.
krbtgt/REALM@REALM). If the credentials are present and not expired,
then the code assumes they are ok and does not acquire new credentials.
If the credentials are expired or not found, the code will then use the
keytab to authenticate.
Based on more feedback from Simo, I made some additional changes:
* Go ahead and reacquire the creds if they have expired or will expire
in 30 seconds - this is not configurable but could be made to be - 30
seconds should be long enough so that the credentials will not expire by
the time they are actually used deep in the ldap/sasl/gssapi/krb code,
and short enough so that this won't cause unnecessary credential churn
* Retry the bind in the case of Ticket expired. There is no way that I
can see to get the actual error code - fortunately the extended ldap
error message has this information
Platforms tested: Fedora 8, Fedora 9
Flag Day: no
Doc impact: no
https://bugzilla.redhat.com/attachment.cgi?id=322914&action=diff
https://bugzilla.redhat.com/show_bug.cgi?id=469261
Resolves: bug 469261
Bug Description: Support server-to-server SASL - kerberos improvements
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: I made several improvements to the kerberos code at
Simo's suggestion
First look for the principal in the ccache. If not found, use the
username if it does not look like a DN. If still not found, construct a
principal using the krb5_sname_to_principal() function to construct
"ldap/fqdn@REALM".
Next, see if the credentials for this principal are still valid. In
order to grab the credentials from the ccache, I needed to construct the
server principal, which in this case is the TGS service principal (e.g.
krbtgt/REALM@REALM). If the credentials are present and not expired,
then the code assumes they are ok and does not acquire new credentials.
If the credentials are expired or not found, the code will then use the
keytab to authenticate.
Platforms tested: Fedora 8, Fedora 9
Flag Day: no
Doc impact: no
https://bugzilla.redhat.com/attachment.cgi?id=322788&action=diff