openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#5644) make test000 core dumps
by michael＠stroeder.com 05 Aug '08

05 Aug '08

Full_Name: Michael Ströder Version: HEAD OS: openSUSE Linux 11.0 URL: Submission from: (NULL) (84.163.95.185) (gdb) bt full #0 0x40462915 in free () from /lib/libc.so.6 No symbol table info available. #1 0x40074ccd in ber_memfree_x (p=0x7fffffff, ctx=0x0) at memory.c:152 __PRETTY_FUNCTION__ = "ber_memfree_x" #2 0x405df014 in ?? () from /usr/lib/libldap-2.4.so.2 No symbol table info available. #3 0x405c1578 in ?? () from /usr/lib/libldap-2.4.so.2 No symbol table info available. #4 0x405ee930 in _fini () from /usr/lib/libldap-2.4.so.2 No symbol table info available. #5 0x40012ebf in ?? () from /lib/ld-linux.so.2 No symbol table info available. #6 0x40013817 in ?? () from /lib/ld-linux.so.2 No symbol table info available. #7 0x40254cb4 in ?? () from /lib/libdl.so.2 No symbol table info available. #8 0x4000de26 in ?? () from /lib/ld-linux.so.2 No symbol table info available. #9 0x402550dc in ?? () from /lib/libdl.so.2 No symbol table info available. #10 0x40254cea in dlclose () from /lib/libdl.so.2 No symbol table info available. #11 0x4024d3a1 in _sasl_done_with_plugins () from /usr/lib/libsasl2.so.2 No symbol table info available. #12 0x40245c20 in sasl_done () from /usr/lib/libsasl2.so.2 No symbol table info available. #13 0x080cc1e4 in slap_sasl_destroy () at sasl.c:1156 No locals. #14 0x080a48c9 in slap_destroy () at init.c:255 rc = 0 #15 0x08050cfb in main (argc=8, argv=0xbfbe2184) at main.c:965 i = 8 no_detach = 1 rc = 0 urls = 0x82d2050 "ldap://localhost:9011/" username = 0x0 groupname = 0x0 sandbox = 0x0 syslogUser = 160 g_argc = 8 g_argv = (char **) 0xbfbe2184 configfile = 0x82d2008 "/home/michael/src/openldap/HEAD/openldap/tests/testrun/slapd.1.conf" configdir = 0x0 serverName = 0xbfbe4079 "lt-slapd" serverMode = 1 scp = (struct sync_cookie *) 0x0 scp_entry = (struct sync_cookie *) 0x0 debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 serverNamePrefix = 0x81f146b "" l = 2097734 slapd_pid_file_unlink = 1 ---Type <return> to continue, or q <return> to quit--- slapd_args_file_unlink = 1 firstopt = 0 __PRETTY_FUNCTION__ = "main"

1 0

Re: (ITS#5639) Digital (PGP-)signature for downloadable sources
by h.b.furuseth＠usit.uio.no 04 Aug '08

04 Aug '08

Kurt(a)OpenLDAP.org writes: >On Aug 4, 2008, at 2:06 PM, h.b.furuseth(a)usit.uio.no wrote: >> Kurt(a)OpenLDAP.org writes: >>> 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. >> >> For that part, signatures in the 'https:' site would help. > > I think you need to re-think that assertion. Er, yes, I was thinking of the "outside" equivalent, hacking DNS and "taking over" that way. I have the impression that's the most common way to "take over" a site, but I may be wrong. -- Hallvard

1 0

Re: (ITS#5639) Digital (PGP-)signature for downloadable sources
by Kurt＠OpenLDAP.org 04 Aug '08

04 Aug '08

On Aug 4, 2008, at 3:23 PM, michael(a)stroeder.com wrote: > Kurt Zeilenga wrote: >> 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". > > I knew this (transition during a major OS update on my local machine). > It's fixed. My point was not wether you knew it or not, but whether any verifier would care. > >> 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. > > Hashes have to be validated out-of-band each time a new release is > published. The trusted keys be have to be validated out-of-band only > each time a new trust anchor key is generated. The point here that an attacker can create the same level of trust for any new signing key they might use (or trust in that no signing was done) for the rouge release as the trust tends to be just publication of the signing key on the web site. And, as I noted, an attacker could just change stable from 2.m.y to 2.n.x, where 2.n.x was some crackable release. Personally, I place a less trust on a signing key I fetch off a website than a hash I get both by email, on a moderated list, that I can verify in the list archives, and on the FTP site. The former is actually seems more subject to MITM attack than the latter. Now, with https:, I would say they have fairly comparable security considerations. Basically, if an attacker owns the website/ftp host, the attacker can fool most everyone. > >> 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. > > There is no 100% security. I already know this. But raising security > level is always an desirable goal. You haven't clearly stated how the security level is actually getting raised through the signing you suggest. > >> 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 have no objections against a single release manager using his > personal > key or a dedicated key for OpenLDAP tar.gz signing stored in your > local > file system reasonably protected by a passphrase. As I see it > you're the > only one packaging the tar.gz. So this should not be too difficult for > you. What about a purely self-signed signing key with finger print published on the website, and possible release announcements. (The latter arguable would be better, as it's more widely published.) [This appears to be the appraoch you've taken with web2ldap.] But, as I've noted, this really doesn't offer significant better security than widely published hashes. However, if what you want is a signing key in which members of the public can personally verify is in the control of the project, that would be more difficult to provide. Or, if what you want is a signing key which is in a wide web of trust, the difficultly depends on the scale of the web of trust desired (to the point of approaching the general public problem). > Well, if you don't want to do that then just leave it... > >> Note that these are human-factor attacks, not attacks based upon any >> weakness in the PGP signing standards or implementations. > > I already know that. This comment was for the peanut gallery. -- Kurt

1 0

Re: (ITS#5639) Digital (PGP-)signature for downloadable sources
by Kurt＠OpenLDAP.org 04 Aug '08

04 Aug '08

On Aug 4, 2008, at 2:06 PM, h.b.furuseth(a)usit.uio.no wrote: > Kurt(a)OpenLDAP.org writes: >> 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. > > For that part, signatures in the 'https:' site would help. I think you need to re-think that assertion. > Not that I'm making an issue of it, I've got OpenLDAP installations > that I didn't verify against any signature right on this host. > > -- > Hallvard > >

1 0

Re: (ITS#5634) str2entry NULL (smr_normalize reqControls 21) when slapadding accesslog-DB with reqControls
by ando＠sys-net.it 04 Aug '08

04 Aug '08

Should be fixed now, please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5624) overlay rwm causes assertion
by ando＠sys-net.it 04 Aug '08

04 Aug '08

This should be now fixed in HEAD; please test. Sorry for the late commit. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5643) Back-relay subordinate issue
by ando＠sys-net.it 04 Aug '08

04 Aug '08

Full_Name: Pierangelo Masarati Version: HEAD,re24,re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.231.225.242) Submitted by: ando Back-relay wants to find the relayed database while parsing the "relay" directive; however, if back-relay is instantiated as subordinate, the relayed database might not exist yet, or it might just not show up because subordinated as well. The issue can be worked around by not defining a relay directive. However, a simple fix appears to consist in deferring relayed database lookup. p.

1 0

Re: (ITS#5634) str2entry NULL (smr_normalize reqControls 21) when slapadding accesslog-DB with reqControls
by ando＠sys-net.it 04 Aug '08

04 Aug '08

----- michael(a)stroeder.com wrote: > Full_Name: Michael Str�der > Version: RE24 > OS: Linux > URL: > Submission from: (NULL) (84.163.81.95) > > > I tried to restore an accesslog > > reqControls: {0}{2.16.840.1.113730.3.4.2} > > <= str2entry NULL (smr_normalize reqControls 21) > slapadd: could not parse entry (line=6) I have a fix, but can't commit right now; I'll try later. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5642) Double free on exit, when specific attributetype is defined
by stef＠memberwebs.com 04 Aug '08

04 Aug '08

Full_Name: Stef Walter Version: 2.4.11 OS: FreeBSD 6.3-RELEASE-p2 URL: Submission from: (NULL) (38.99.5.20) When the following line is present in the schema (or slapd.conf), then upon exit any slap* process aborts due to a double free of memory: attributetype ( 278.1.3.6.1 NAME 'requireClass' SUP objectClass ) The OID is obviously fictional. This can be triggered reliably by running: # slaptest

1 0

Re: (ITS#5639) Digital (PGP-)signature for downloadable sources
by michael＠stroeder.com 04 Aug '08

04 Aug '08

Kurt Zeilenga wrote: > 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". I knew this (transition during a major OS update on my local machine). It's fixed. > 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. Hashes have to be validated out-of-band each time a new release is published. The trusted keys be have to be validated out-of-band only each time a new trust anchor key is generated. > 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. There is no 100% security. I already know this. But raising security level is always an desirable goal. > 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 have no objections against a single release manager using his personal key or a dedicated key for OpenLDAP tar.gz signing stored in your local file system reasonably protected by a passphrase. As I see it you're the only one packaging the tar.gz. So this should not be too difficult for you. Well, if you don't want to do that then just leave it... > Note that these are human-factor attacks, not attacks based upon any > weakness in the PGP signing standards or implementations. I already know that. Ciao, Michael.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs