(ITS#8704) LMDB add option to use prev meta page
by hyc＠openldap.org
Full_Name: Howard Chu
Version: LMDB 0.9
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (83.136.45.220)
Submitted by: hyc
Generally, running LMDB in NOSYNC mode means all integrity guarantees are gone,
in even of a system crash. However, if some other thread runs mdb_env_sync
periodically it's possible that the older DB state is still consistent, even if
slightly out of date. I have always intended to add an env flag for using the
older meta page, to potentially access a DB even after the latest txn snapshot
was corrupted.
A patch for this has been contributed, although support in the command-line
tools still needs to be added.
6 years, 1 month
Re: (ITS#8703) slapd should create its PID file before dropping privileges
by michael＠orlitzky.com
The problem scenario looks like the following:
1. I run "/etc/init.d/slapd start" to start the daemon.
2. slapd drops to the "slapd" user.
3. slapd writes its PID file, now owned by the "slapd" user.
4. Someone compromises the daemon, which sits on the open network.
5. The attacker is generally limited in what he can do because the
daemon doesn't run as root. However, he can write "1" into the
slapd.pid file, and he does.
6. I run "/etc/init.d/slapd stop" to stop the daemon while I investigate
the weird behavior resulting from the hack.
7. Oops, the machine reboots, because I killed PID 1.
6 years, 1 month
Re: (ITS#8703) slapd should create its PID file before dropping privileges
by hyc＠symas.com
michael(a)orlitzky.com wrote:
> Full_Name: Michael Orlitzky
> Version: 2.4.45
> OS: Gentoo
> URL:
> Submission from: (NULL) (98.218.46.55)
>
>
> The slapd daemon should create its PID file before dropping privileges. This
> represents a minor security issue; additional factors are needed to make it
> exploitable.
>
> Why?
>
> The purpose of the PID file is to hold the PID of the running daemon,
> so that later it can be stopped, restarted, or otherwise signalled
> (many daemons reload their configurations in response to a SIGHUP).
> To fulfill that purpose, the contents of the PID file need to be
> trustworthy. If the PID file is writable by a non-root user, then he
> can replace its contents with the PID of a root process.
Not sure this is a valid concern. The uid used to run services should not
actually have a valid login shell, and thus should not ever be usable for any
purpose other than running the daemon from init.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
6 years, 1 month
(ITS#8703) slapd should create its PID file before dropping privileges
by michael＠orlitzky.com
Full_Name: Michael Orlitzky
Version: 2.4.45
OS: Gentoo
URL:
Submission from: (NULL) (98.218.46.55)
The slapd daemon should create its PID file before dropping privileges. This
represents a minor security issue; additional factors are needed to make it
exploitable.
Why?
The purpose of the PID file is to hold the PID of the running daemon,
so that later it can be stopped, restarted, or otherwise signalled
(many daemons reload their configurations in response to a SIGHUP).
To fulfill that purpose, the contents of the PID file need to be
trustworthy. If the PID file is writable by a non-root user, then he
can replace its contents with the PID of a root process. Afterwards,
any attempt to signal the PID contained in the PID file will instead
signal a root process chosen by the non-root user (a vulnerability).
This is commonly exploitable by init scripts that are run as root and
which blindly trust the contents of their PID files. If one daemon
flushes its cache in response to SIGUSR2 and another daemon drops all
connections in response to SIGUSR2, it is not hard to imagine a
denial-of-service by the user of the first daemon against the second.
6 years, 1 month
(ITS#8702) SLAPD_MAX_DAEMON_THREADS is too small
by hyc＠openldap.org
Full_Name: Howard Chu
Version: HEAD
OS: Solaris 11.3
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (31.216.236.133)
Submitted by: hyc
Was benchmarking on an Oracle M8 box with 2048 SPARC VCPUs. With 1024 slapd
threads configured, we needed 64 listener threads and 64 threadqueues to
eliminate slapd bottlenecks, but the current default in daemon.c only allows up
to 16 listener threads.
It's a #ifndef so easily overridable at compile time, but 16 is probably too
small in this age of processors with more and more cores.
6 years, 1 month
(ITS#8701) account usability control for password less logins
by manikya.prabhu.salveru＠oracle.com
Full_Name: Manikya
Version: 2.4.44
OS: Solaris 11.3
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (141.143.213.56)
Solaris ldap clients are configured for pam_ldap and requires a control to
validate users for password less logins.
http://docs.oracle.com/cd/E19253-01/816-4556/schemas-250/index.html
>From open-ds documentation.
account usability control
The account usability control provides a pair of request and response controls
that can be used to determine whether a user account may be used for
authenticating to the server.
The request control has an OID of 1.3.6.1.4.1.42.2.27.9.5.8 and does not include
a value. It should only be included in search request messages.
The corresponding response control has an OID of 1.3.6.1.4.1.42.2.27.9.5.8 (the
same as the request control), and it will be included in any search result entry
messages for a search request that includes the account usability request
control.
The value for the account usability response control is encoded as follows:
ACCOUNT_USABLE_RESPONSE ::= CHOICE {
is_available [0] INTEGER, -- Seconds before expiration --
is_not_available [1] MORE_INFO }
MORE_INFO ::= SEQUENCE {
inactive [0] BOOLEAN DEFAULT FALSE,
reset [1] BOOLEAN DEFAULT FALSE,
expired [2] BOOLEAN DEFAULT_FALSE,
remaining_grace [3] INTEGER OPTIONAL,
seconds_before_unlock [4] INTEGER OPTIONAL }
If the user account is available, then the control will include the number of
seconds until the user's password expires, or -1 if password expiration is not
enabled. If the user's account is not available, then the control will provide
the reason it is unavailable.
6 years, 1 month
(ITS#8700) Compile error
by papachoco＠gmail.com
Full_Name: Carlos Sanchez
Version: 2.4.45
OS: macOS 10.12.6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (68.97.40.67)
I am getting the error below while compiling openldap 2.4.45 on the latest
macOS sierra (10.12.6). I am only setting two configuration options
configure-options =
--disable-slapd
--disable-slurpd
Undefined symbols for architecture x86_64:
"_ERR_remove_thread_state", referenced from:
_tlso_destroy in libldap.a(tls_o.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [apitest] Error 1
make[1]: *** [all-common] Error 1
make: *** [all-common] Error 1
openldap_client: Command failed with exit code 2: make
6 years, 1 month
(ITS#8699) More for cursor_del with DUPSORT
by hyc＠openldap.org
Full_Name: Howard Chu
Version: LMDB 0.9.21
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (31.216.236.133)
Submitted by: hyc
When deleting a series of records in a loop using mdb_cursor_get(MDB_NEXT) in a
DUPSORT DB, when deleting the last dup of one key, the first dup of the next key
gets skipped on the next iteration.
This appears to be due to an incomplete fix to ITS#8622
6 years, 1 month
(ITS#8698) ppolicy: responses from pwdCheckModule discarded when using an extended password modify
by tim＠bishnet.net
Full_Name: Tim Bishop
Version: 2.4.42
OS: Ubuntu 16.04
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (2001:630:340:1141::13)
Whilst this issue was discovered on OpenLDAP 2.4.42, the code is unchanged on
the latest version, so I believe it is still applicable there.
The high-level overview of the problem is that when using the ppolicy overlay
with an external pwdCheckModule, and a password is changed using the LDAPv3
Password Modify (RFC 3062) extended operation (ie. ldappasswd), the message
returned by the pwdCheckModule is not passed back to the user. All other failure
messages generated in ppolicy are returned correctly.
I've looked into this and discovered the cause of the problem. We can start by
looking at where the message is returned:
https://github.com/openldap/openldap/blob/OPENLDAP_REL_ENG_2_4_42/servers...
The check_password_quality function calls out to the pwdCheckModule which sets
txt to point at a malloc'd string. Here we set rs->sr_text to point to that, and
make a note to free it later. This is the exception, in all other cases, as can
be seen a few lines below, rs->sr_text is set to a static string.
Later on, the result is returned to the user:
https://github.com/openldap/openldap/blob/OPENLDAP_REL_ENG_2_4_42/servers...
And then after that, it is free'd.
This all works fine for a normal password modify operation. The problem occurs
when we wrap this in an extended password modify:
https://github.com/openldap/openldap/blob/OPENLDAP_REL_ENG_2_4_42/servers...
This line is where the call into ppolicy originates (with a few steps in
between), and then on line 237 below we see a call to send_ldap_extended (which
returns rs->sr_text to the user) that includes a pointer to rs. In cases where
rs->sr_text is a static string this is fine, but where we've set it to a
response from pwdCheckModule it has at this point been free'd and set to NULL
before send_ldap_extended gets a chance to send it.
The result is that confusingly the response from pwdCheckModule is returned for
non-extended password changes, but not for extended ones.
I don't have a fix for this since I'm not familiar enough with the slapd code.
But I'd imagine it'd require setting a flag either in rs or op to note when
free'ing of rs->sr_text is required, and then move that free call as far out as
necessary (back to where rs is created in connection.c?) so that rs->sr_text is
always available.
6 years, 1 month
(ITS#8697) Remove refptr symbols from slapd.def
by quanah＠openldap.org
Full_Name: Quanah Gibson-Mount
Version: 2.4.45
OS: Windows 10 64-bit
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (47.208.148.239)
When building OpenLDAP with a newer version of gcc, dlltool now exports a ton of
".refptr.FUNCTION" values out to the slapd.def file. This breaks the build
process, as they aren't real functions. This is due to this change to gcc:
https://gcc.gnu.org/ml/gcc-patches/2013-03/msg00858.html
Fix is simple enough, simply update our sed that we run against slapd.def:
quanah@ub16:~/git/openldap/openldap-head/servers/slapd$ git diff .
diff --git a/servers/slapd/Makefile.in b/servers/slapd/Makefile.in
index 177ad28..0327537 100644
--- a/servers/slapd/Makefile.in
+++ b/servers/slapd/Makefile.in
@@ -210,7 +210,7 @@ slapd.def: libbackends.a liboverlays.a version.o
dlltool --exclude-symbols main,ServiceMain@8 --export-all-symbols \
--output-def $@.tmp $$objs;
echo EXPORTS > $@
- $(SED) -e 1,2d -e 's/ @ [0-9][0-9]*//' $@.tmp | sort >> $@
+ $(SED) -e 1,2d -e 's/ @ [0-9][0-9]*//' -e '/\.refptr\./d' $@.tmp | sort
>> $@
$(RM) $@.tmp
symdummy.c: slapd.def
6 years, 2 months
