openldap-bugs August 2008

openldap-bugs@openldap.org

40 participants
169 discussions

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

Re: (ITS#5586) SLAPD crashing with SIGABRT in connection.c on Solaris - reference through nil pointer
by dbb＠st-andrews.ac.uk 04 Aug '08

04 Aug '08

Just an update, still present in 2.4.11, backtrace below. Still can't work out why it's happening, it's something in the way that sendmail uses ldap and not the actual queries that cause the crash. I can replay the connections and searches to the server, and I've used Suns ldap load testing software to load up the server way over what we ever see and I can't replicate the SIGABRT or crash it in any other way. Any help appreciated. Thanks, Duncan # /usr/local/SUNWspro/bin/dbx /source/openldap-2.4.11/servers/slapd/.libs/slapd ./slapd-2.4.11-core-1300-4-8-08 For information about new features see `help changes' To remove this message, put `dbxenv suppress_startup_message 7.6' in your .dbxrc Reading slapd core file header read successfully Reading ld.so.1 Reading libldap_r-2.4.so.2.1.0 Reading liblber-2.4.so.2.1.0 Reading libltdl.so.3.1.5 Reading libdb-4.2.so Reading libicuuc.so.3 Reading libicudata.so.3 Reading libsasl2.so.2.0.22 Reading libdl.so.1 Reading libssl.so.0.9.8 Reading libcrypto.so.0.9.8 Reading libresolv.so.2 Reading libgen.so.1 Reading libnsl.so.1 Reading libsocket.so.1 Reading libc.so.1 Reading libgcc_s.so.1 Reading libgcc_s.so.1 Reading libpthread.so.1 Reading libm.so.2 Reading libCrun.so.1 Reading libc_psr.so.1 t@2 (l@2) terminated by signal ABRT (Abort) 0xfe2c0f90: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xfe2c0fa0 Current function is connection_next 871 assert( connections[*index].c_conn_state == SLAP_C_INVALID ); (dbx) where current thread: t@2 [1] __lwp_kill(0x0, 0x6, 0x0, 0x6, 0xfc00, 0x0), at 0xfe2c0f90 [2] raise(0x6, 0x0, 0xfe2a4a98, 0xffffffff, 0xfe2e8284, 0x6), at 0xfe25fd78 [3] abort(0xfdfff3f0, 0x1, 0xfe2e9288, 0xa83f0, 0xfe2eb298, 0x0), at 0xfe23ff98 [4] __assert(0x1a1808, 0x1a183c, 0x367, 0x0, 0xa810c, 0x1d7b80), at 0xfe2401d4 =>[5] connection_next(c = (nil), index = 0xfdfff6d4), line 871 in "connection.c" [6] connections_timeout_idle(now = 1217851229), line 225 in "connection.c" [7] slapd_daemon_task(ptr = (nil)), line 2152 in "daemon.c" (dbx) threads t@1 a l@1 ?() LWP suspended in __lwp_wait() o> t@2 a l@2 slapd_daemon_task() signal SIGABRT in __lwp_kill() t@3 a l@3 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@4 a l@4 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@5 a l@5 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@6 a l@6 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() Current function is connection_next 871 assert( connections[*index].c_conn_state == SLAP_C_INVALID ); (dbx) dump c_struct = 1 index = 0xfdfff6d4 c = (nil) (dbx) up Current function is connections_timeout_idle 225 c = connection_next( c, &connindex ) ) (dbx) dump connindex = 21 c = 0x2c14b0 now = 1217851229 i = 3 (dbx) up Current function is slapd_daemon_task 2152 connections_timeout_idle( now ); (dbx) dump rtask = (nil) cat = RECORD nwriters = 0 nfds = 68 writefds = RECORD at = 1 now = 1217851229 ns = 0 nrfds = 0 readfds = RECORD tdelta = 1 nwfds = 0 tvp = 0xfdfffb60 i = 22 tv = RECORD last_idle_check = 1217851221 l = 1 idle = RECORD ptr = (nil) ebadf = 0

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: > 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. 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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs August 2008