Re: (ITS#5639) Digital (PGP-)signature for downloadable sources
by Kurt＠OpenLDAP.org
On Aug 3, 2008, at 11:38 AM, michael(a)stroeder.com wrote:
> Full_Name: Michael Ströder
> Version: HEAD
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (84.163.112.78)
>
>
> Source files downloadable fomr http://www.openldap.org should be
> digitally
> signed. It's common practice to use PGP (GnuPG) for that.
Saying this should be done solely because you claim it is "common
practice" is lame. It would be better to state what attacks you
worry about, and why you think providing digital signatures using a
trustworthy signing key, and what requirements are for this
trustworthy signing key.
But I note the practice is, itself, lame. Often there is no reason to
trust the signing key other than where the link to the signing key was
published. Often the signature itself is not widely published, or
errors in providing it too far common to raise concerns in case the
signature publication fails (by error or attack).
For instance, web_ldap says it provides a signature for a digital
release, but clicking on the link provides a page which says "Not
found". Maybe your releases have been hacked, but most likely its
just publication issue. Most verifiers faced with such such a "Not
found" message will just not perform the verification. Often they
won't even bother to raise an issue to the publisher.
And if an attacker successfully takes over the main website, we have
to realize that they can replace everything. Maybe they will replace
whatever text we have about digital signatures with a statement that
signatures are no longer provided, and then delete them. Or they may
fake publication errors. They could even fake an email to the
announcement list that signatures are temporarily not provided due to
operational reasons, or announce a new signing key.
Fortunately, it is unlikely that such an attack would go unnoticed for
long period of time. I would argue that if takeover was a major
threat (which it might well be), that more time should be spent
detecting a takeover (we have some in place).
I also find it interesting that you suggest signing tarballs and not
announcement messages. I note that an attacker need not modify a
tarball, or cause a new tarball to be distributed, to successfully
mount an attack against the downloader. One could simply point
"stable" to a known problematic release. As the signature for the
problematic release would be valid, it doesn't help the downloader in
detecting they got the wrong release. Of course, even if you sign
release messages, the attacker can still replace the current messages
with prior ones whose signatures would still be valid.
But, as I noted with hashes, the fact that release messages are widely
published may make it more likely that such problems will be detected.
I note as well that properly deploying release signing requires more
than script modification. For instance, one does need to consider
that the host to sign the releases might itself been taken over and
the implications of such a takeover. Also, in signing announcements,
considerable testing would need to take place to ensure produced
signatures were actually verifiable (lots of things muck with email in
ways that invalid email signatures).
Anyways, for this to go anywhere, I think you or others advocating it
need to more precisely state which attacks you concerned about, how
you think digital signatures will help, and detail requirements on
that signing (in particular, requirements on signing key so trust can
be established and maintained).
I note that GNU PGP folks say that verification of a wide published
message digest is sufficient to ensure the integrity of their releases.
Basically, PGP signing here offers little value as an attacker who has
supplanted the other protections (namely widely distributed message
digests) is in position to convince most every downloader than the
current release is not signed, or was signed but that signature is not
currently available, or was signed by some key other than that
previously used by the distributor.
Note that these are human-factor attacks, not attacks based upon any
weakness in the PGP signing standards or implementations.
14 years, 7 months
(ITS#5641) Segmentation fault - slaptest and slapd
by hfranzke＠tee.toshiba.de
Full_Name: Helmut Franzke
Version: 2.4.11 / 2.4.9
OS: Ubuntu server 8.04.1 / Centos 4.6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (192.109.150.105)
I could get slaptest/slapd to produce a segmentation fault by using the unique
overlay and a unique_uri with a base dn. This behaviour depends on the position
of the overlay/unique_uri in slapd.conf and doesn't appear if you don't use a
base dn regardless of the position. (I know an overlay should be defined after
the other configuration settings have been set. I encountered this bug when I
put it in the first part by mistake, see below)
I could reproduce this with OpenLdap 2.4.9 from Ubuntu 8.04.1 server as well as
a fresh compiled OpenLdap 2.4.11 on Ubuntu 8.04.1 and Centos 4.6
How to reproduce:
Take a (very simple) OpenLdap installation and put the overlay stuff before the
suffix configuration:
-------------------------------------------------------------
.
.
moduleload unique
.
.
#######################################################################
# Specific Directives for database #1, of type hdb:
# Database specific directives apply to this databasse until another
# 'database' directive occurs
database hdb
# The base of your directory in database #1
overlay unique
unique_uri ldap:///"dc=my-domain,dc=com"?gidNumber?sub
suffix "dc=my-domain,dc=com"
.
.
-------------------------------------------------------
Then check the configuration:
ldapmaster-dev:/etc/ldap#slaptest
Segmentation fault
ldapmaster-dev:/etc/ldap#slapd -d 4
Segmentation fault
Putting the overlay stuff at the end of the database section or the suffix
configuration before the overly stuff it works as expected. It also works
without a base dn (unique_uri ldap:///?gidNumber?sub) regardless of the
position.
14 years, 7 months
(ITS#5640) slapd scans too many objects at startup
by ali.pouya＠free.fr
Full_Name: Ali Pouya
Version: 2.4.11
OS: Linux 2.6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (145.242.11.4)
I have a test directory with two mirrors A and B and a replica C connected to
A.
I usaually use server A for write operations.
I encounter the following problems :
1) If the data base is initiated in stand alone (so serverID defaults to zero)
and then I set serverIDs 1 and 2 for A and B then each time I start up slapd on
C it scans all of the objects writtent on A afterwards, producing the followin
log for each object :
======================================================
entry_decode: "cn=testr1,ou=resources,ou=mefi,o=gouv,c=fr"
<= entry_decode(cn=testr1,ou=resources,ou=mefi,o=gouv,c=fr)
=> bdb_dn2id("cn=testr1,ou=resources,ou=mefi,o=gouv,c=fr")
<= bdb_dn2id: got id=0x9
=> test_filter
GE
=> access_allowed: search access to "cn=testr1,ou=resources,ou=mefi,o=gouv,c=fr"
"entryCSN" requested
<= root access granted
=> access_allowed: search access granted by manage(=mwrscxd)
<= test_filter 6
======================================================
For a directory with 10 million objects the this takes more than one hour (slapd
is running but the service is not available).
If I set serverID=3 on the replica C the problem disapears.
2) If I do only one write operation on B, then I get two contextCSN values,
which is normal.
But il this case slapd on B scans, at each startup, all objecs written on A
after the write operation on B.
The log and the effect are similar to those explained above.
Should I consider this as a normal behaviour or a bug ?
My mirror configuration is similar to the one recommended in Admin's Guide.
Of course I can provide more detailed information if required.
Thanks for your HELP
Best Regards
Ali
14 years, 7 months
Re: (ITS#5638) Openldap 2.4.11 aborts in oc_filter in back_bdb/search.c
by hyc＠symas.com
stef(a)memberwebs.com wrote:
> Full_Name: Stef
> Version: 2.4.11
> OS: FreeBSD 6.3-RELEASE-p2
> URL:
> Submission from: (NULL) (38.99.5.20)
>
>
> After upgrading to 2.4.11 all our LDAP servers would abort when modifications
> were made to them. Here are the last messages leading up to and including the
> abort:
This appears to be the same as ITS#5581. Please direct all further emails to
that item instead.
It looks like there's a problem in your slapo-unique configuration.
>
> => bdb_list_candidates 0xa0
> => bdb_filter_candidates
> OR
> => bdb_list_candidates 0xa1
> => bdb_filter_candidates
> EQUALITY
> => bdb_equality_candidates (objectClass)
> => key_read
> bdb_idl_fetch_key: [b49d1940]
> <= bdb_index_read: failed (-30989)
> <= bdb_equality_candidates: id=0, first=0, last=0
> <= bdb_filter_candidates: id=0 first=0 last=0
> => bdb_filter_candidates
> <= bdb_filter_candidates: id=0 first=0 last=0
> <= bdb_list_candidates: id=0 first=0 last=0
> <= bdb_filter_candidates: id=0 first=0 last=0
> <= bdb_list_candidates: id=0 first=1 last=0
> <= bdb_filter_candidates: id=0 first=1 last=0
> bdb_search_candidates: id=0 first=1 last=0
> bdb_search: no candidates
> send_ldap_result: conn=7 op=13 p=3
> send_ldap_result: err=0 matched="" text=""
> => unique_search found 0 records
> ==> unique_search
> str2filter "(&(?=error)(|))"
> put_filter: "(&(?=error)(|))"
> put_filter: AND
> put_filter_list "(?=error)(|)"
> put_filter: "(?=error)"
> put_filter: simple
> put_simple_filter: "?=error"
> => bdb_search
> bdb_dn2entry("dc=fam")
> => access_allowed: search access to "dc=fam" "entry" requested
> <= root access granted
> => access_allowed: search access granted by manage(=mwrscxd)
> search_candidates: base="dc=fam" (0x00000001) scope=2
> Assertion failed: (f != NULL), function oc_filter, file search.c, line 970.
> Abort trap: 6
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
14 years, 7 months
Re: (ITS#5635) slapi SLAPI_MODIFY_MODS mod->mod_op offset.
by hyc＠symas.com
m.d.t.evans(a)qmul.ac.uk wrote:
> Full_Name: Martin Evans
> Version: 2.4.10
> OS: Linux/F9
> URL:
> Submission from: (NULL) (138.37.8.59)
>
>
> In a slapi pre-modify function (SLAPI_PLUGIN_PRE_MODIFY_FN) you can get a null
> terminated array of LDAPMod modifications. Like so:
>
> /* get list of mods */
> if (slapi_pblock_get(pb,SLAPI_MODIFY_MODS,&mods) || !mods) {
> LOG("[%i] Error retrieving LDAPMods.\n",conn_id);
> return (PLUGIN_STOP);
> }
> DEBUG("[%i] Got LDAPMods.",conn_id);
>
>
> If you loop over these and extract the mod_op values which are held in
> mod->mod_op, the values seem to be offset by 128. i.e. an add operation, which
> should have a value of 0 (LDAP_MOD_ADD) has a value of 128. A delete operation,
> should have 2 (LDAP_MOD_DELETE) it seems to be set to 130.
>
> The numbers differ only in the 8th bit. So I'm wondering if there is a strange
> signed/unsigned int conversion thing going on somewhere.
That's the LDAP_MOD_BVALUES flag. There's no bug here, this ITS will be closed.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
14 years, 7 months
(ITS#5638) Openldap 2.4.11 aborts in oc_filter in back_bdb/search.c
by stef＠memberwebs.com
Full_Name: Stef
Version: 2.4.11
OS: FreeBSD 6.3-RELEASE-p2
URL:
Submission from: (NULL) (38.99.5.20)
After upgrading to 2.4.11 all our LDAP servers would abort when modifications
were made to them. Here are the last messages leading up to and including the
abort:
=> bdb_list_candidates 0xa0
=> bdb_filter_candidates
OR
=> bdb_list_candidates 0xa1
=> bdb_filter_candidates
EQUALITY
=> bdb_equality_candidates (objectClass)
=> key_read
bdb_idl_fetch_key: [b49d1940]
<= bdb_index_read: failed (-30989)
<= bdb_equality_candidates: id=0, first=0, last=0
<= bdb_filter_candidates: id=0 first=0 last=0
=> bdb_filter_candidates
<= bdb_filter_candidates: id=0 first=0 last=0
<= bdb_list_candidates: id=0 first=0 last=0
<= bdb_filter_candidates: id=0 first=0 last=0
<= bdb_list_candidates: id=0 first=1 last=0
<= bdb_filter_candidates: id=0 first=1 last=0
bdb_search_candidates: id=0 first=1 last=0
bdb_search: no candidates
send_ldap_result: conn=7 op=13 p=3
send_ldap_result: err=0 matched="" text=""
=> unique_search found 0 records
==> unique_search
str2filter "(&(?=error)(|))"
put_filter: "(&(?=error)(|))"
put_filter: AND
put_filter_list "(?=error)(|)"
put_filter: "(?=error)"
put_filter: simple
put_simple_filter: "?=error"
=> bdb_search
bdb_dn2entry("dc=fam")
=> access_allowed: search access to "dc=fam" "entry" requested
<= root access granted
=> access_allowed: search access granted by manage(=mwrscxd)
search_candidates: base="dc=fam" (0x00000001) scope=2
Assertion failed: (f != NULL), function oc_filter, file search.c, line 970.
Abort trap: 6
14 years, 7 months
(ITS#5637) dynacl broken when an access mask has been already applied by previous ACL rule
by kouk＠noc.uoa.gr
Full_Name: Kostantinos Koukopoulos
Version: 2.4.11
OS: Solaris
URL: ftp://ftp.openldap.org/incoming/kostantinos-koukopoulos-080801.diff
Submission from: (NULL) (195.134.100.30)
There is a bug in the function 'slap_acl_mask' in servers/slapd/acl.c that
affects the processing of dynacls. In particular the code attempts to apply
ACL_ACCESS2PRIV to a variable already containing a slap_mask_t value. By chance
this does not make a difference except when the dynacl rule is applied after a
'break' in a previous rule that has altered the default mask. It appears that
the intention was to check whether the requested access level applies to the
dynacl rule access mask. Instead the check is made against the current applied
mask. The referenced patch fixes this issue by passing the requested access
level as an extra parameter to the function and using it for the check.
14 years, 7 months
(ITS#5636) performance improvement in ACI evaluation
by stef＠noc.uoa.gr
Full_Name: Stefanos Stamatis
Version: 2.4.11
OS: Solaris
URL: ftp://ftp.openldap.org/incoming/stefanos-stamatis-080801.diff
Submission from: (NULL) (195.134.100.30)
The function 'aci_mask' in servers/slapd/aci.c will evaluate the type and
subject part of an ACI even if the 'action;rights;attr;' part of the ACI does
not apply. This is bad for performance, especially if the subject is a set which
dereferences the objects 'user' or 'this'. The referenced patch solves this
issue by fixing 'aci_list_get_rights' to return 0 if the returned mask does not
effect a change.
14 years, 7 months
