[Sts-sponsors] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
** Changed in: libmemcached (Ubuntu Trusty) Status: Fix Committed => Invalid -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1573594 Title: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling Status in libmemcached package in Ubuntu: Fix Released Status in libmemcached source package in Trusty: Invalid Status in libmemcached source package in Xenial: Fix Released Status in libmemcached source package in Bionic: Fix Released Status in libmemcached source package in Cosmic: Fix Released Status in libmemcached source package in Disco: Fix Released Status in libmemcached package in Debian: New Bug description: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start [Test Case] This bug is difficult to reproduce since it depends on the contents of the stack. However, here is a test case using the fix on Bionic that shows that this fix does not cause any problems. For testing you need 1) A memcached server. You can setup one by following the instructions in [1], or (what I did) create one in the cloud [2]. 2) A client test program to connect to the memcached server. One can be found in [3]. This simple test connects to a memcache server and test basic get/set operations. Copy paste the C code into a file (sals_test.c) and compile with : gcc -o sasl_test -O2 sasl_test.c -lmemcached -pthread 3) On a machine with the updated version of libmemcached in which the fix is applied : jo@bionic-vm:~$ dpkg -l | grep libmemcached ii libhashkit-dev:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms (development files) ii libhashkit2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms ii libmemcached-dbg:amd641.0.18-4.2ubuntu0.18.04.1 amd64Debug Symbols for libmemcached ii libmemcached-dev:amd641.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server (development files) ii libmemcached-tools1.0.18-4.2ubuntu0.18.04.1 amd64Commandline tools for talking to memcached via libmemcached ii libmemcached11:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server ii libmemcachedutil2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64library implementing connection pooling for libmemcached Run the sals_test binary : #./sasl_test [username] [password] [server] In my case using the credentials and the server created in step 1 : jo@bionic-vm:~$ ./sasl_test 88BAB0 1A99094B77C8935ED9F1461C767DB1F9 mc2.dev.eu.ec2.memcachier.com Get/Set success! [1] https://blog.couchbase.com/sasl-memcached-now-available/ [2] https://www.memcachier.com/ [3] https://blog.memcachier.com/2014/11/05/ubuntu-libmemcached-and-sasl-support/ [Regression Potential] This fix initialises the buffer to 0. Any potential regression may include failure of the authentication when using SASL. * When running autopkgtest for xenial/armhf it fails on gearmand : http://autopkgtest.ubuntu.com/packages/g/gearmand/xenial/armhf . However this is a long standing issue with gearmand and it is not related with the current SRU. [Other Info] This bug affects trusty and later. * rmadison: libmemcached | 1.0.8-1ubuntu2 | trusty | source libmemcached | 1.0.18-4.1 | xenial | source libmemcached | 1.0.18-4.2 | bionic | source libmemcached | 1.0.18-4.2 | cosmic | source libmemcached | 1.0.18-4.2 | disco | source * Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919696 * Upstream seems pretty quiet since 2014 Unfortunately, because the project seems more or less dead ... it seems like we won't be able submit anything upstream and go straight to fixing Debian and Ubuntu.
[Sts-sponsors] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
This bug was fixed in the package libmemcached - 1.0.18-4.2ubuntu0.18.04.1 --- libmemcached (1.0.18-4.2ubuntu0.18.04.1) bionic; urgency=medium * d/p/fixing_missing_null_termination.patch: - Fix missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling (LP: #1573594) -- Ioanna Alifieraki Fri, 18 Jan 2019 12:41:28 + ** Changed in: libmemcached (Ubuntu Bionic) Status: Fix Committed => Fix Released ** Changed in: libmemcached (Ubuntu Xenial) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1573594 Title: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling Status in libmemcached package in Ubuntu: Fix Released Status in libmemcached source package in Trusty: Fix Committed Status in libmemcached source package in Xenial: Fix Released Status in libmemcached source package in Bionic: Fix Released Status in libmemcached source package in Cosmic: Fix Released Status in libmemcached source package in Disco: Fix Released Status in libmemcached package in Debian: New Bug description: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start [Test Case] This bug is difficult to reproduce since it depends on the contents of the stack. However, here is a test case using the fix on Bionic that shows that this fix does not cause any problems. For testing you need 1) A memcached server. You can setup one by following the instructions in [1], or (what I did) create one in the cloud [2]. 2) A client test program to connect to the memcached server. One can be found in [3]. This simple test connects to a memcache server and test basic get/set operations. Copy paste the C code into a file (sals_test.c) and compile with : gcc -o sasl_test -O2 sasl_test.c -lmemcached -pthread 3) On a machine with the updated version of libmemcached in which the fix is applied : jo@bionic-vm:~$ dpkg -l | grep libmemcached ii libhashkit-dev:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms (development files) ii libhashkit2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms ii libmemcached-dbg:amd641.0.18-4.2ubuntu0.18.04.1 amd64Debug Symbols for libmemcached ii libmemcached-dev:amd641.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server (development files) ii libmemcached-tools1.0.18-4.2ubuntu0.18.04.1 amd64Commandline tools for talking to memcached via libmemcached ii libmemcached11:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server ii libmemcachedutil2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64library implementing connection pooling for libmemcached Run the sals_test binary : #./sasl_test [username] [password] [server] In my case using the credentials and the server created in step 1 : jo@bionic-vm:~$ ./sasl_test 88BAB0 1A99094B77C8935ED9F1461C767DB1F9 mc2.dev.eu.ec2.memcachier.com Get/Set success! [1] https://blog.couchbase.com/sasl-memcached-now-available/ [2] https://www.memcachier.com/ [3] https://blog.memcachier.com/2014/11/05/ubuntu-libmemcached-and-sasl-support/ [Regression Potential] This fix initialises the buffer to 0. Any potential regression may include failure of the authentication when using SASL. * When running autopkgtest for xenial/armhf it fails on gearmand : http://autopkgtest.ubuntu.com/packages/g/gearmand/xenial/armhf . However this is a long standing issue with gearmand and it is not related with the current SRU. [Other Info] This bug affects trusty and later. * rmadison: libmemcached | 1.0.8-1ubuntu2 | trusty | source libmemcached |
[Sts-sponsors] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
This bug was fixed in the package libmemcached - 1.0.18-4.1ubuntu2 --- libmemcached (1.0.18-4.1ubuntu2) xenial; urgency=medium * d/p/fixing_missing_null_termination.patch: - Fix missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling (LP: #1573594) -- Ioanna Alifieraki Fri, 18 Jan 2019 12:57:57 + -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1573594 Title: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling Status in libmemcached package in Ubuntu: Fix Released Status in libmemcached source package in Trusty: Fix Committed Status in libmemcached source package in Xenial: Fix Released Status in libmemcached source package in Bionic: Fix Released Status in libmemcached source package in Cosmic: Fix Released Status in libmemcached source package in Disco: Fix Released Status in libmemcached package in Debian: New Bug description: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start [Test Case] This bug is difficult to reproduce since it depends on the contents of the stack. However, here is a test case using the fix on Bionic that shows that this fix does not cause any problems. For testing you need 1) A memcached server. You can setup one by following the instructions in [1], or (what I did) create one in the cloud [2]. 2) A client test program to connect to the memcached server. One can be found in [3]. This simple test connects to a memcache server and test basic get/set operations. Copy paste the C code into a file (sals_test.c) and compile with : gcc -o sasl_test -O2 sasl_test.c -lmemcached -pthread 3) On a machine with the updated version of libmemcached in which the fix is applied : jo@bionic-vm:~$ dpkg -l | grep libmemcached ii libhashkit-dev:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms (development files) ii libhashkit2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms ii libmemcached-dbg:amd641.0.18-4.2ubuntu0.18.04.1 amd64Debug Symbols for libmemcached ii libmemcached-dev:amd641.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server (development files) ii libmemcached-tools1.0.18-4.2ubuntu0.18.04.1 amd64Commandline tools for talking to memcached via libmemcached ii libmemcached11:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server ii libmemcachedutil2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64library implementing connection pooling for libmemcached Run the sals_test binary : #./sasl_test [username] [password] [server] In my case using the credentials and the server created in step 1 : jo@bionic-vm:~$ ./sasl_test 88BAB0 1A99094B77C8935ED9F1461C767DB1F9 mc2.dev.eu.ec2.memcachier.com Get/Set success! [1] https://blog.couchbase.com/sasl-memcached-now-available/ [2] https://www.memcachier.com/ [3] https://blog.memcachier.com/2014/11/05/ubuntu-libmemcached-and-sasl-support/ [Regression Potential] This fix initialises the buffer to 0. Any potential regression may include failure of the authentication when using SASL. * When running autopkgtest for xenial/armhf it fails on gearmand : http://autopkgtest.ubuntu.com/packages/g/gearmand/xenial/armhf . However this is a long standing issue with gearmand and it is not related with the current SRU. [Other Info] This bug affects trusty and later. * rmadison: libmemcached | 1.0.8-1ubuntu2 | trusty | source libmemcached | 1.0.18-4.1 | xenial | source libmemcached | 1.0.18-4.2 | bionic | source libmemcached | 1.0.18-4.2 | cosmic | source libmemcached | 1.0.18-4.2 | disco | source * Debian
[Sts-sponsors] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
This bug was fixed in the package libmemcached - 1.0.18-4.2ubuntu0.18.10.1 --- libmemcached (1.0.18-4.2ubuntu0.18.10.1) cosmic; urgency=medium * d/p/fixing_missing_null_termination.patch: - Fix missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling (LP: #1573594) -- Ioanna Alifieraki Fri, 18 Jan 2019 13:36:33 + ** Changed in: libmemcached (Ubuntu Cosmic) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1573594 Title: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling Status in libmemcached package in Ubuntu: Fix Released Status in libmemcached source package in Trusty: Fix Committed Status in libmemcached source package in Xenial: Fix Released Status in libmemcached source package in Bionic: Fix Released Status in libmemcached source package in Cosmic: Fix Released Status in libmemcached source package in Disco: Fix Released Status in libmemcached package in Debian: New Bug description: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start [Test Case] This bug is difficult to reproduce since it depends on the contents of the stack. However, here is a test case using the fix on Bionic that shows that this fix does not cause any problems. For testing you need 1) A memcached server. You can setup one by following the instructions in [1], or (what I did) create one in the cloud [2]. 2) A client test program to connect to the memcached server. One can be found in [3]. This simple test connects to a memcache server and test basic get/set operations. Copy paste the C code into a file (sals_test.c) and compile with : gcc -o sasl_test -O2 sasl_test.c -lmemcached -pthread 3) On a machine with the updated version of libmemcached in which the fix is applied : jo@bionic-vm:~$ dpkg -l | grep libmemcached ii libhashkit-dev:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms (development files) ii libhashkit2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms ii libmemcached-dbg:amd641.0.18-4.2ubuntu0.18.04.1 amd64Debug Symbols for libmemcached ii libmemcached-dev:amd641.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server (development files) ii libmemcached-tools1.0.18-4.2ubuntu0.18.04.1 amd64Commandline tools for talking to memcached via libmemcached ii libmemcached11:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server ii libmemcachedutil2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64library implementing connection pooling for libmemcached Run the sals_test binary : #./sasl_test [username] [password] [server] In my case using the credentials and the server created in step 1 : jo@bionic-vm:~$ ./sasl_test 88BAB0 1A99094B77C8935ED9F1461C767DB1F9 mc2.dev.eu.ec2.memcachier.com Get/Set success! [1] https://blog.couchbase.com/sasl-memcached-now-available/ [2] https://www.memcachier.com/ [3] https://blog.memcachier.com/2014/11/05/ubuntu-libmemcached-and-sasl-support/ [Regression Potential] This fix initialises the buffer to 0. Any potential regression may include failure of the authentication when using SASL. * When running autopkgtest for xenial/armhf it fails on gearmand : http://autopkgtest.ubuntu.com/packages/g/gearmand/xenial/armhf . However this is a long standing issue with gearmand and it is not related with the current SRU. [Other Info] This bug affects trusty and later. * rmadison: libmemcached | 1.0.8-1ubuntu2 | trusty | source libmemcached | 1.0.18-4.1 | xenial | source libmemcached | 1.0.18-4.2 | bionic | source
[Sts-sponsors] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
Thanks for verifying! I'll drop the trusty package from -proposed and release the others into -updates. -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1573594 Title: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling Status in libmemcached package in Ubuntu: Fix Released Status in libmemcached source package in Trusty: Fix Committed Status in libmemcached source package in Xenial: Fix Released Status in libmemcached source package in Bionic: Fix Released Status in libmemcached source package in Cosmic: Fix Released Status in libmemcached source package in Disco: Fix Released Status in libmemcached package in Debian: New Bug description: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start [Test Case] This bug is difficult to reproduce since it depends on the contents of the stack. However, here is a test case using the fix on Bionic that shows that this fix does not cause any problems. For testing you need 1) A memcached server. You can setup one by following the instructions in [1], or (what I did) create one in the cloud [2]. 2) A client test program to connect to the memcached server. One can be found in [3]. This simple test connects to a memcache server and test basic get/set operations. Copy paste the C code into a file (sals_test.c) and compile with : gcc -o sasl_test -O2 sasl_test.c -lmemcached -pthread 3) On a machine with the updated version of libmemcached in which the fix is applied : jo@bionic-vm:~$ dpkg -l | grep libmemcached ii libhashkit-dev:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms (development files) ii libhashkit2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms ii libmemcached-dbg:amd641.0.18-4.2ubuntu0.18.04.1 amd64Debug Symbols for libmemcached ii libmemcached-dev:amd641.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server (development files) ii libmemcached-tools1.0.18-4.2ubuntu0.18.04.1 amd64Commandline tools for talking to memcached via libmemcached ii libmemcached11:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server ii libmemcachedutil2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64library implementing connection pooling for libmemcached Run the sals_test binary : #./sasl_test [username] [password] [server] In my case using the credentials and the server created in step 1 : jo@bionic-vm:~$ ./sasl_test 88BAB0 1A99094B77C8935ED9F1461C767DB1F9 mc2.dev.eu.ec2.memcachier.com Get/Set success! [1] https://blog.couchbase.com/sasl-memcached-now-available/ [2] https://www.memcachier.com/ [3] https://blog.memcachier.com/2014/11/05/ubuntu-libmemcached-and-sasl-support/ [Regression Potential] This fix initialises the buffer to 0. Any potential regression may include failure of the authentication when using SASL. * When running autopkgtest for xenial/armhf it fails on gearmand : http://autopkgtest.ubuntu.com/packages/g/gearmand/xenial/armhf . However this is a long standing issue with gearmand and it is not related with the current SRU. [Other Info] This bug affects trusty and later. * rmadison: libmemcached | 1.0.8-1ubuntu2 | trusty | source libmemcached | 1.0.18-4.1 | xenial | source libmemcached | 1.0.18-4.2 | bionic | source libmemcached | 1.0.18-4.2 | cosmic | source libmemcached | 1.0.18-4.2 | disco | source * Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919696 * Upstream seems pretty quiet since 2014 Unfortunately, because the project seems more or less dead ... it seems like we won't be able submit anything upstream and go straight to
[Sts-sponsors] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
Ionna, Let's then request the SRU verification team to drop the package for trusty-proposed. If SASL is not supported in the Trusty pkg, there is no point to complete the SRU for Trusty. Additionally, since Trusty is near to its EOL, I don't see good reason/justification to justify the effort/work to enable SASL on the package. Also enabling SASL, IMHO, won't be consider a "bug fix", but a "new feature". For all the reasons above, let's simply drop the pkg from trusty- proposed. - Eric -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1573594 Title: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling Status in libmemcached package in Ubuntu: Fix Released Status in libmemcached source package in Trusty: Fix Committed Status in libmemcached source package in Xenial: Fix Committed Status in libmemcached source package in Bionic: Fix Committed Status in libmemcached source package in Cosmic: Fix Committed Status in libmemcached source package in Disco: Fix Released Status in libmemcached package in Debian: New Bug description: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start [Test Case] This bug is difficult to reproduce since it depends on the contents of the stack. However, here is a test case using the fix on Bionic that shows that this fix does not cause any problems. For testing you need 1) A memcached server. You can setup one by following the instructions in [1], or (what I did) create one in the cloud [2]. 2) A client test program to connect to the memcached server. One can be found in [3]. This simple test connects to a memcache server and test basic get/set operations. Copy paste the C code into a file (sals_test.c) and compile with : gcc -o sasl_test -O2 sasl_test.c -lmemcached -pthread 3) On a machine with the updated version of libmemcached in which the fix is applied : jo@bionic-vm:~$ dpkg -l | grep libmemcached ii libhashkit-dev:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms (development files) ii libhashkit2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms ii libmemcached-dbg:amd641.0.18-4.2ubuntu0.18.04.1 amd64Debug Symbols for libmemcached ii libmemcached-dev:amd641.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server (development files) ii libmemcached-tools1.0.18-4.2ubuntu0.18.04.1 amd64Commandline tools for talking to memcached via libmemcached ii libmemcached11:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server ii libmemcachedutil2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64library implementing connection pooling for libmemcached Run the sals_test binary : #./sasl_test [username] [password] [server] In my case using the credentials and the server created in step 1 : jo@bionic-vm:~$ ./sasl_test 88BAB0 1A99094B77C8935ED9F1461C767DB1F9 mc2.dev.eu.ec2.memcachier.com Get/Set success! [1] https://blog.couchbase.com/sasl-memcached-now-available/ [2] https://www.memcachier.com/ [3] https://blog.memcachier.com/2014/11/05/ubuntu-libmemcached-and-sasl-support/ [Regression Potential] This fix initialises the buffer to 0. Any potential regression may include failure of the authentication when using SASL. * When running autopkgtest for xenial/armhf it fails on gearmand : http://autopkgtest.ubuntu.com/packages/g/gearmand/xenial/armhf . However this is a long standing issue with gearmand and it is not related with the current SRU. [Other Info] This bug affects trusty and later. * rmadison: libmemcached | 1.0.8-1ubuntu2 | trusty | source libmemcached | 1.0.18-4.1 | xenial | source libmemcached |
[Sts-sponsors] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
Verification on Trusty : **Verification failed** libmemcached on Trusty does not support SASL authentication Repeating the steps described in the [Test Case] of bug description : Install the trusty-proposed packages $ dpkg -l | grep libmemcached ii libhashkit-dev 1.0.8-1ubuntu2.1 amd64 libmemcached hashing functions and algorithms (development files) ii libhashkit2:amd64 1.0.8-1ubuntu2.1 amd64 libmemcached hashing functions and algorithms ii libmemcached-dev 1.0.8-1ubuntu2.1 amd64 C and C++ client library to the memcached server (development files) ii libmemcached-tools 1.0.8-1ubuntu2.1 amd64 Commandline tools for talking to memcached via libmemcached ii libmemcached10:amd64 1.0.8-1ubuntu2.1 amd64 C and C++ client library to the memcached server ii libmemcachedprotocol0:amd641.0.8-1ubuntu2.1 amd64 library implementing the memcached protocol ii libmemcachedutil2:amd641.0.8-1ubuntu2.1 amd64 library implementing connection pooling for libmemcached $ ./sasl_test 88BAB0 1A99094B77C8935ED9F1461C767DB1F9 mc2.dev.eu.ec2.memcachier.com Couldn't setup SASL auth: ACTION NOT SUPPORTED Set failed: AUTHENTICATION FAILURE ** Tags removed: verification-needed-trusty ** Tags added: verification-failed-trusty -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1573594 Title: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling Status in libmemcached package in Ubuntu: Fix Released Status in libmemcached source package in Trusty: Fix Committed Status in libmemcached source package in Xenial: Fix Committed Status in libmemcached source package in Bionic: Fix Committed Status in libmemcached source package in Cosmic: Fix Committed Status in libmemcached source package in Disco: Fix Released Status in libmemcached package in Debian: New Bug description: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start [Test Case] This bug is difficult to reproduce since it depends on the contents of the stack. However, here is a test case using the fix on Bionic that shows that this fix does not cause any problems. For testing you need 1) A memcached server. You can setup one by following the instructions in [1], or (what I did) create one in the cloud [2]. 2) A client test program to connect to the memcached server. One can be found in [3]. This simple test connects to a memcache server and test basic get/set operations. Copy paste the C code into a file (sals_test.c) and compile with : gcc -o sasl_test -O2 sasl_test.c -lmemcached -pthread 3) On a machine with the updated version of libmemcached in which the fix is applied : jo@bionic-vm:~$ dpkg -l | grep libmemcached ii libhashkit-dev:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms (development files) ii libhashkit2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms ii libmemcached-dbg:amd641.0.18-4.2ubuntu0.18.04.1 amd64Debug Symbols for libmemcached ii libmemcached-dev:amd641.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server (development files) ii libmemcached-tools1.0.18-4.2ubuntu0.18.04.1 amd64Commandline tools for talking to memcached via libmemcached ii libmemcached11:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server ii libmemcachedutil2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64library implementing connection pooling for libmemcached Run the sals_test binary : #./sasl_test
[Sts-sponsors] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
Correction on comment #28 : Verification on Bionic Repeating the steps described in the [Test Case] of bug description : Install the bionic-proposed packages $ dpkg -l | grep libmem ii libhashkit-dev:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms (development files) ii libhashkit2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms ii libmemcached-dev:amd641.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server (development files) ii libmemcached-tools1.0.18-4.2ubuntu0.18.04.1 amd64Commandline tools for talking to memcached via libmemcached ii libmemcached11:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server ii libmemcachedutil2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64library implementing connection pooling for libmemcached $ ./sasl_test 88BAB0 1A99094B77C8935ED9F1461C767DB1F9 mc2.dev.eu.ec2.memcachier.com Get/Set success! -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1573594 Title: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling Status in libmemcached package in Ubuntu: Fix Released Status in libmemcached source package in Trusty: Fix Committed Status in libmemcached source package in Xenial: Fix Committed Status in libmemcached source package in Bionic: Fix Committed Status in libmemcached source package in Cosmic: Fix Committed Status in libmemcached source package in Disco: Fix Released Status in libmemcached package in Debian: New Bug description: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start [Test Case] This bug is difficult to reproduce since it depends on the contents of the stack. However, here is a test case using the fix on Bionic that shows that this fix does not cause any problems. For testing you need 1) A memcached server. You can setup one by following the instructions in [1], or (what I did) create one in the cloud [2]. 2) A client test program to connect to the memcached server. One can be found in [3]. This simple test connects to a memcache server and test basic get/set operations. Copy paste the C code into a file (sals_test.c) and compile with : gcc -o sasl_test -O2 sasl_test.c -lmemcached -pthread 3) On a machine with the updated version of libmemcached in which the fix is applied : jo@bionic-vm:~$ dpkg -l | grep libmemcached ii libhashkit-dev:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms (development files) ii libhashkit2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms ii libmemcached-dbg:amd641.0.18-4.2ubuntu0.18.04.1 amd64Debug Symbols for libmemcached ii libmemcached-dev:amd641.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server (development files) ii libmemcached-tools1.0.18-4.2ubuntu0.18.04.1 amd64Commandline tools for talking to memcached via libmemcached ii libmemcached11:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server ii libmemcachedutil2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64library implementing connection pooling for libmemcached Run the sals_test binary : #./sasl_test [username] [password] [server] In my case using the credentials and the server created in step 1 : jo@bionic-vm:~$ ./sasl_test 88BAB0 1A99094B77C8935ED9F1461C767DB1F9 mc2.dev.eu.ec2.memcachier.com Get/Set success! [1]
[Sts-sponsors] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
Verification on Cosmic : Repeating the steps described in the [Test Case] of bug description : Install the cosmic-proposed packages $ dpkg -l | grep libmemcached ii libhashkit-dev:amd64 1.0.18-4.2ubuntu0.18.10.1 amd64libmemcached hashing functions and algorithms (development files) ii libhashkit2:amd64 1.0.18-4.2ubuntu0.18.10.1 amd64libmemcached hashing functions and algorithms ii libmemcached-dev:amd641.0.18-4.2ubuntu0.18.10.1 amd64C and C++ client library to the memcached server (development files) ii libmemcached-tools1.0.18-4.2ubuntu0.18.10.1 amd64Commandline tools for talking to memcached via libmemcached ii libmemcached11:amd64 1.0.18-4.2ubuntu0.18.10.1 amd64C and C++ client library to the memcached server ii libmemcachedutil2:amd64 1.0.18-4.2ubuntu0.18.10.1 amd64library implementing connection pooling for libmemcached $ ./sasl_test 88BAB0 1A99094B77C8935ED9F1461C767DB1F9 mc2.dev.eu.ec2.memcachier.com Get/Set success! ** Tags removed: verification-needed-cosmic ** Tags added: verification-done-cosmic -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1573594 Title: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling Status in libmemcached package in Ubuntu: Fix Released Status in libmemcached source package in Trusty: Fix Committed Status in libmemcached source package in Xenial: Fix Committed Status in libmemcached source package in Bionic: Fix Committed Status in libmemcached source package in Cosmic: Fix Committed Status in libmemcached source package in Disco: Fix Released Status in libmemcached package in Debian: New Bug description: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start [Test Case] This bug is difficult to reproduce since it depends on the contents of the stack. However, here is a test case using the fix on Bionic that shows that this fix does not cause any problems. For testing you need 1) A memcached server. You can setup one by following the instructions in [1], or (what I did) create one in the cloud [2]. 2) A client test program to connect to the memcached server. One can be found in [3]. This simple test connects to a memcache server and test basic get/set operations. Copy paste the C code into a file (sals_test.c) and compile with : gcc -o sasl_test -O2 sasl_test.c -lmemcached -pthread 3) On a machine with the updated version of libmemcached in which the fix is applied : jo@bionic-vm:~$ dpkg -l | grep libmemcached ii libhashkit-dev:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms (development files) ii libhashkit2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms ii libmemcached-dbg:amd641.0.18-4.2ubuntu0.18.04.1 amd64Debug Symbols for libmemcached ii libmemcached-dev:amd641.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server (development files) ii libmemcached-tools1.0.18-4.2ubuntu0.18.04.1 amd64Commandline tools for talking to memcached via libmemcached ii libmemcached11:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server ii libmemcachedutil2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64library implementing connection pooling for libmemcached Run the sals_test binary : #./sasl_test [username] [password] [server] In my case using the credentials and the server created in step 1 : jo@bionic-vm:~$ ./sasl_test 88BAB0 1A99094B77C8935ED9F1461C767DB1F9
[Sts-sponsors] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
Verification on Bionic : Repeating the steps described in the [Test Case] of bug description : Install the bionic-proposed packages $ dpkg -l | grep libmemcache ii libhashkit-dev:amd64 1.0.18-4.2 amd64libmemcached hashing functions and algorithms (development files) ii libhashkit2:amd64 1.0.18-4.2 amd64libmemcached hashing functions and algorithms ii libmemcached-dev:amd641.0.18-4.2 amd64C and C++ client library to the memcached server (development files) ii libmemcached-tools1.0.18-4.2 amd64Commandline tools for talking to memcached via libmemcached ii libmemcached11:amd64 1.0.18-4.2 amd64C and C++ client library to the memcached server ii libmemcachedutil2:amd64 1.0.18-4.2 amd64library implementing connection pooling for libmemcached $ ./sasl_test 88BAB0 1A99094B77C8935ED9F1461C767DB1F9 mc2.dev.eu.ec2.memcachier.com Get/Set success! ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1573594 Title: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling Status in libmemcached package in Ubuntu: Fix Released Status in libmemcached source package in Trusty: Fix Committed Status in libmemcached source package in Xenial: Fix Committed Status in libmemcached source package in Bionic: Fix Committed Status in libmemcached source package in Cosmic: Fix Committed Status in libmemcached source package in Disco: Fix Released Status in libmemcached package in Debian: New Bug description: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start [Test Case] This bug is difficult to reproduce since it depends on the contents of the stack. However, here is a test case using the fix on Bionic that shows that this fix does not cause any problems. For testing you need 1) A memcached server. You can setup one by following the instructions in [1], or (what I did) create one in the cloud [2]. 2) A client test program to connect to the memcached server. One can be found in [3]. This simple test connects to a memcache server and test basic get/set operations. Copy paste the C code into a file (sals_test.c) and compile with : gcc -o sasl_test -O2 sasl_test.c -lmemcached -pthread 3) On a machine with the updated version of libmemcached in which the fix is applied : jo@bionic-vm:~$ dpkg -l | grep libmemcached ii libhashkit-dev:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms (development files) ii libhashkit2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms ii libmemcached-dbg:amd641.0.18-4.2ubuntu0.18.04.1 amd64Debug Symbols for libmemcached ii libmemcached-dev:amd641.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server (development files) ii libmemcached-tools1.0.18-4.2ubuntu0.18.04.1 amd64Commandline tools for talking to memcached via libmemcached ii libmemcached11:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server ii libmemcachedutil2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64library implementing connection pooling for libmemcached Run the sals_test binary : #./sasl_test [username] [password] [server] In my case using the credentials and the server created in step 1 : jo@bionic-vm:~$ ./sasl_test 88BAB0 1A99094B77C8935ED9F1461C767DB1F9 mc2.dev.eu.ec2.memcachier.com Get/Set
[Sts-sponsors] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
Verification on Xenial : Repeating the steps described in the [Test Case] of bug description : Install the xenial-proposed packages $ dpkg -l | grep libmem ii libhashkit-dev 1.0.18-4.1ubuntu2 amd64 libmemcached hashing functions and algorithms (development files) ii libhashkit2:amd64 1.0.18-4.1ubuntu2 amd64 libmemcached hashing functions and algorithms ii libmemcached-dev1.0.18-4.1ubuntu2 amd64 C and C++ client library to the memcached server (development files) ii libmemcached-tools 1.0.18-4.1ubuntu2 amd64 Commandline tools for talking to memcached via libmemcached ii libmemcached11:amd641.0.18-4.1ubuntu2 amd64 C and C++ client library to the memcached server ii libmemcachedutil2:amd64 1.0.18-4.1ubuntu2 amd64 library implementing connection pooling for libmemcached $ ./sasl_test 88BAB0 1A99094B77C8935ED9F1461C767DB1F9 mc2.dev.eu.ec2.memcachier.com Get/Set success! ** Tags removed: verification-needed-xenial ** Tags added: verification-done-xenial -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1573594 Title: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling Status in libmemcached package in Ubuntu: Fix Released Status in libmemcached source package in Trusty: Fix Committed Status in libmemcached source package in Xenial: Fix Committed Status in libmemcached source package in Bionic: Fix Committed Status in libmemcached source package in Cosmic: Fix Committed Status in libmemcached source package in Disco: Fix Released Status in libmemcached package in Debian: New Bug description: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start [Test Case] This bug is difficult to reproduce since it depends on the contents of the stack. However, here is a test case using the fix on Bionic that shows that this fix does not cause any problems. For testing you need 1) A memcached server. You can setup one by following the instructions in [1], or (what I did) create one in the cloud [2]. 2) A client test program to connect to the memcached server. One can be found in [3]. This simple test connects to a memcache server and test basic get/set operations. Copy paste the C code into a file (sals_test.c) and compile with : gcc -o sasl_test -O2 sasl_test.c -lmemcached -pthread 3) On a machine with the updated version of libmemcached in which the fix is applied : jo@bionic-vm:~$ dpkg -l | grep libmemcached ii libhashkit-dev:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms (development files) ii libhashkit2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms ii libmemcached-dbg:amd641.0.18-4.2ubuntu0.18.04.1 amd64Debug Symbols for libmemcached ii libmemcached-dev:amd641.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server (development files) ii libmemcached-tools1.0.18-4.2ubuntu0.18.04.1 amd64Commandline tools for talking to memcached via libmemcached ii libmemcached11:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server ii libmemcachedutil2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64library implementing connection pooling for libmemcached Run the sals_test binary : #./sasl_test [username] [password] [server] In my case using the credentials and the server created in step 1 : jo@bionic-vm:~$ ./sasl_test 88BAB0 1A99094B77C8935ED9F1461C767DB1F9 mc2.dev.eu.ec2.memcachier.com Get/Set success! [1] https://blog.couchbase.com/sasl-memcached-now-available/ [2] https://www.memcachier.com/ [3] https://blog.memcachier.com/2014/11/05/ubuntu-libmemcached-and-sasl-support/
[Sts-sponsors] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
** Description changed: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start - [Test Case] This bug is difficult to reproduce since it depends on the contents of the stack. However, here is a test case using the fix on Bionic that shows that this fix does not cause any problems. For testing you need 1) A memcached server. -You can setup one by following the instructions in [1], -or (what I did) create one in the cloud [2]. + You can setup one by following the instructions in [1], + or (what I did) create one in the cloud [2]. 2) A client test program to connect to the memcached server. -One can be found in [3]. -This simple test connects to a memcache server and test basic get/set operations. -Copy paste the C code into a file (sals_test.c) and compile with : -gcc -o sasl_test -O2 sasl_test.c -lmemcached -pthread + One can be found in [3]. + This simple test connects to a memcache server and test basic get/set operations. + Copy paste the C code into a file (sals_test.c) and compile with : + gcc -o sasl_test -O2 sasl_test.c -lmemcached -pthread 3) On a machine with the updated version of libmemcached in which the fix is applied : -jo@bionic-vm:~$ dpkg -l | grep libmemcached + jo@bionic-vm:~$ dpkg -l | grep libmemcached ii libhashkit-dev:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms (development files) ii libhashkit2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms ii libmemcached-dbg:amd641.0.18-4.2ubuntu0.18.04.1 amd64Debug Symbols for libmemcached ii libmemcached-dev:amd641.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server (development files) ii libmemcached-tools1.0.18-4.2ubuntu0.18.04.1 amd64Commandline tools for talking to memcached via libmemcached ii libmemcached11:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server ii libmemcachedutil2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64library implementing connection pooling for libmemcached -Run the sals_test binary : -#./sasl_test [username] [password] [server] - -In my case using the credentials and the server created in step 1 : -jo@bionic-vm:~$ ./sasl_test 88BAB0 1A99094B77C8935ED9F1461C767DB1F9 mc2.dev.eu.ec2.memcachier.com -Get/Set success! + Run the sals_test binary : + #./sasl_test [username] [password] [server] + + In my case using the credentials and the server created in step 1 : + jo@bionic-vm:~$ ./sasl_test 88BAB0 1A99094B77C8935ED9F1461C767DB1F9 mc2.dev.eu.ec2.memcachier.com + Get/Set success! [1] https://blog.couchbase.com/sasl-memcached-now-available/ [2] https://www.memcachier.com/ [3] https://blog.memcachier.com/2014/11/05/ubuntu-libmemcached-and-sasl-support/ [Regression Potential] This fix initialises the buffer to 0. Any potential regression may include failure of the authentication when using SASL. + + * When running autopkgtest for xenial/armhf it fails on gearmand : http://autopkgtest.ubuntu.com/packages/g/gearmand/xenial/armhf . + However this is a long standing issue with gearmand and it is not related with the current SRU. + [Other Info] This bug affects trusty and later. * rmadison: libmemcached | 1.0.8-1ubuntu2 | trusty | source libmemcached | 1.0.18-4.1 | xenial | source libmemcached | 1.0.18-4.2 | bionic | source libmemcached | 1.0.18-4.2 | cosmic | source libmemcached | 1.0.18-4.2 | disco | source * Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919696 * Upstream seems pretty quiet since 2014 Unfortunately, because the project seems more or less dead ... it seems like we won't be able submit anything upstream and go straight to fixing Debian and Ubuntu. -
[Sts-sponsors] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
** Project changed: libmemcached => ubuntu-translations ** No longer affects: ubuntu-translations -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1573594 Title: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling Status in libmemcached package in Ubuntu: Fix Released Status in libmemcached source package in Trusty: Fix Committed Status in libmemcached source package in Xenial: Fix Committed Status in libmemcached source package in Bionic: Fix Committed Status in libmemcached source package in Cosmic: Fix Committed Status in libmemcached source package in Disco: Fix Released Status in libmemcached package in Debian: New Bug description: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start [Test Case] This bug is difficult to reproduce since it depends on the contents of the stack. However, here is a test case using the fix on Bionic that shows that this fix does not cause any problems. For testing you need 1) A memcached server. You can setup one by following the instructions in [1], or (what I did) create one in the cloud [2]. 2) A client test program to connect to the memcached server. One can be found in [3]. This simple test connects to a memcache server and test basic get/set operations. Copy paste the C code into a file (sals_test.c) and compile with : gcc -o sasl_test -O2 sasl_test.c -lmemcached -pthread 3) On a machine with the updated version of libmemcached in which the fix is applied : jo@bionic-vm:~$ dpkg -l | grep libmemcached ii libhashkit-dev:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms (development files) ii libhashkit2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms ii libmemcached-dbg:amd641.0.18-4.2ubuntu0.18.04.1 amd64Debug Symbols for libmemcached ii libmemcached-dev:amd641.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server (development files) ii libmemcached-tools1.0.18-4.2ubuntu0.18.04.1 amd64Commandline tools for talking to memcached via libmemcached ii libmemcached11:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server ii libmemcachedutil2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64library implementing connection pooling for libmemcached Run the sals_test binary : #./sasl_test [username] [password] [server] In my case using the credentials and the server created in step 1 : jo@bionic-vm:~$ ./sasl_test 88BAB0 1A99094B77C8935ED9F1461C767DB1F9 mc2.dev.eu.ec2.memcachier.com Get/Set success! [1] https://blog.couchbase.com/sasl-memcached-now-available/ [2] https://www.memcachier.com/ [3] https://blog.memcachier.com/2014/11/05/ubuntu-libmemcached-and-sasl-support/ [Regression Potential] This fix initialises the buffer to 0. Any potential regression may include failure of the authentication when using SASL. [Other Info] This bug affects trusty and later. * rmadison: libmemcached | 1.0.8-1ubuntu2 | trusty | source libmemcached | 1.0.18-4.1 | xenial | source libmemcached | 1.0.18-4.2 | bionic | source libmemcached | 1.0.18-4.2 | cosmic | source libmemcached | 1.0.18-4.2 | disco | source * Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919696 * Upstream seems pretty quiet since 2014 Unfortunately, because the project seems more or less dead ... it seems like we won't be able submit anything upstream and go straight to fixing Debian and Ubuntu. - Repo: bzr branch lp:libmemcached - Last commit: revno: 1113 [merge] committer: Continuous Integration branch nick: workspace timestamp: Sun 2014-02-16 03:31:37 -0800 message: Merge
[Sts-sponsors] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
Thanks Łukasz, this looks appropriate for an SRU update. Thanks -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1573594 Title: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling Status in libmemcached: New Status in libmemcached package in Ubuntu: Fix Released Status in libmemcached source package in Trusty: Fix Committed Status in libmemcached source package in Xenial: Fix Committed Status in libmemcached source package in Bionic: Fix Committed Status in libmemcached source package in Cosmic: Fix Committed Status in libmemcached source package in Disco: Fix Released Status in libmemcached package in Debian: New Bug description: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start [Test Case] This bug is difficult to reproduce since it depends on the contents of the stack. However, here is a test case using the fix on Bionic that shows that this fix does not cause any problems. For testing you need 1) A memcached server. You can setup one by following the instructions in [1], or (what I did) create one in the cloud [2]. 2) A client test program to connect to the memcached server. One can be found in [3]. This simple test connects to a memcache server and test basic get/set operations. Copy paste the C code into a file (sals_test.c) and compile with : gcc -o sasl_test -O2 sasl_test.c -lmemcached -pthread 3) On a machine with the updated version of libmemcached in which the fix is applied : jo@bionic-vm:~$ dpkg -l | grep libmemcached ii libhashkit-dev:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms (development files) ii libhashkit2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms ii libmemcached-dbg:amd641.0.18-4.2ubuntu0.18.04.1 amd64Debug Symbols for libmemcached ii libmemcached-dev:amd641.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server (development files) ii libmemcached-tools1.0.18-4.2ubuntu0.18.04.1 amd64Commandline tools for talking to memcached via libmemcached ii libmemcached11:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server ii libmemcachedutil2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64library implementing connection pooling for libmemcached Run the sals_test binary : #./sasl_test [username] [password] [server] In my case using the credentials and the server created in step 1 : jo@bionic-vm:~$ ./sasl_test 88BAB0 1A99094B77C8935ED9F1461C767DB1F9 mc2.dev.eu.ec2.memcachier.com Get/Set success! [1] https://blog.couchbase.com/sasl-memcached-now-available/ [2] https://www.memcachier.com/ [3] https://blog.memcachier.com/2014/11/05/ubuntu-libmemcached-and-sasl-support/ [Regression Potential] This fix initialises the buffer to 0. Any potential regression may include failure of the authentication when using SASL. [Other Info] This bug affects trusty and later. * rmadison: libmemcached | 1.0.8-1ubuntu2 | trusty | source libmemcached | 1.0.18-4.1 | xenial | source libmemcached | 1.0.18-4.2 | bionic | source libmemcached | 1.0.18-4.2 | cosmic | source libmemcached | 1.0.18-4.2 | disco | source * Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919696 * Upstream seems pretty quiet since 2014 Unfortunately, because the project seems more or less dead ... it seems like we won't be able submit anything upstream and go straight to fixing Debian and Ubuntu. - Repo: bzr branch lp:libmemcached - Last commit: revno: 1113 [merge] committer: Continuous Integration branch nick: workspace timestamp: Sun 2014-02-16 03:31:37 -0800 message: Merge
[Sts-sponsors] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
Hello Stefan, or anyone else affected, Accepted libmemcached into cosmic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libmemcached/1.0.18-4.2ubuntu0.18.10.1 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-cosmic to verification-done-cosmic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-cosmic. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: libmemcached (Ubuntu Cosmic) Status: In Progress => Fix Committed ** Tags added: verification-needed verification-needed-cosmic ** Changed in: libmemcached (Ubuntu Bionic) Status: In Progress => Fix Committed ** Tags added: verification-needed-bionic -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1573594 Title: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling Status in libmemcached: New Status in libmemcached package in Ubuntu: Fix Released Status in libmemcached source package in Trusty: Fix Committed Status in libmemcached source package in Xenial: Fix Committed Status in libmemcached source package in Bionic: Fix Committed Status in libmemcached source package in Cosmic: Fix Committed Status in libmemcached source package in Disco: Fix Released Status in libmemcached package in Debian: New Bug description: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start [Test Case] This bug is difficult to reproduce since it depends on the contents of the stack. However, here is a test case using the fix on Bionic that shows that this fix does not cause any problems. For testing you need 1) A memcached server. You can setup one by following the instructions in [1], or (what I did) create one in the cloud [2]. 2) A client test program to connect to the memcached server. One can be found in [3]. This simple test connects to a memcache server and test basic get/set operations. Copy paste the C code into a file (sals_test.c) and compile with : gcc -o sasl_test -O2 sasl_test.c -lmemcached -pthread 3) On a machine with the updated version of libmemcached in which the fix is applied : jo@bionic-vm:~$ dpkg -l | grep libmemcached ii libhashkit-dev:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms (development files) ii libhashkit2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms ii libmemcached-dbg:amd641.0.18-4.2ubuntu0.18.04.1 amd64Debug Symbols for libmemcached ii libmemcached-dev:amd641.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server (development files) ii libmemcached-tools1.0.18-4.2ubuntu0.18.04.1 amd64Commandline tools for talking to memcached via libmemcached ii libmemcached11:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server ii libmemcachedutil2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64library implementing connection pooling for libmemcached
[Sts-sponsors] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
I accepted this to -proposed, but since this seems to be a security- related fix, I would really want the security team to take a look at the change and decide whether this should actually go through -security or both. -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1573594 Title: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling Status in libmemcached: New Status in libmemcached package in Ubuntu: Fix Released Status in libmemcached source package in Trusty: Fix Committed Status in libmemcached source package in Xenial: Fix Committed Status in libmemcached source package in Bionic: Fix Committed Status in libmemcached source package in Cosmic: Fix Committed Status in libmemcached source package in Disco: Fix Released Status in libmemcached package in Debian: New Bug description: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start [Test Case] This bug is difficult to reproduce since it depends on the contents of the stack. However, here is a test case using the fix on Bionic that shows that this fix does not cause any problems. For testing you need 1) A memcached server. You can setup one by following the instructions in [1], or (what I did) create one in the cloud [2]. 2) A client test program to connect to the memcached server. One can be found in [3]. This simple test connects to a memcache server and test basic get/set operations. Copy paste the C code into a file (sals_test.c) and compile with : gcc -o sasl_test -O2 sasl_test.c -lmemcached -pthread 3) On a machine with the updated version of libmemcached in which the fix is applied : jo@bionic-vm:~$ dpkg -l | grep libmemcached ii libhashkit-dev:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms (development files) ii libhashkit2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms ii libmemcached-dbg:amd641.0.18-4.2ubuntu0.18.04.1 amd64Debug Symbols for libmemcached ii libmemcached-dev:amd641.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server (development files) ii libmemcached-tools1.0.18-4.2ubuntu0.18.04.1 amd64Commandline tools for talking to memcached via libmemcached ii libmemcached11:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server ii libmemcachedutil2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64library implementing connection pooling for libmemcached Run the sals_test binary : #./sasl_test [username] [password] [server] In my case using the credentials and the server created in step 1 : jo@bionic-vm:~$ ./sasl_test 88BAB0 1A99094B77C8935ED9F1461C767DB1F9 mc2.dev.eu.ec2.memcachier.com Get/Set success! [1] https://blog.couchbase.com/sasl-memcached-now-available/ [2] https://www.memcachier.com/ [3] https://blog.memcachier.com/2014/11/05/ubuntu-libmemcached-and-sasl-support/ [Regression Potential] This fix initialises the buffer to 0. Any potential regression may include failure of the authentication when using SASL. [Other Info] This bug affects trusty and later. * rmadison: libmemcached | 1.0.8-1ubuntu2 | trusty | source libmemcached | 1.0.18-4.1 | xenial | source libmemcached | 1.0.18-4.2 | bionic | source libmemcached | 1.0.18-4.2 | cosmic | source libmemcached | 1.0.18-4.2 | disco | source * Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919696 * Upstream seems pretty quiet since 2014 Unfortunately, because the project seems more or less dead ... it seems like we won't be able submit anything upstream and go straight to fixing Debian and Ubuntu. - Repo: bzr branch lp:libmemcached - Last
[Sts-sponsors] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
[Additionnal Sponsor note] --- Xenial --- Rejected: File libmemcached_1.0.18-4.1ubuntu1.debian.tar.xz already exists in Primary Archive for Ubuntu, but uploaded version has different contents. See more information about this error in https://help.launchpad.net/Packaging/UploadErrors. Files specified in DSC are broken or missing, skipping package unpack verification. --- I had to bump the version for Xenial from "1.0.18-4ubuntu1" to "1.0.18-4ubuntu2". "1.0.18-4ubuntu1" has already been uploaded/built back in 2015 and got superseded/deleted for some reasons that I not aware of, therefore can't be use again. # https://launchpad.net/ubuntu/+source/libmemcached/+publishinghistory DateStatus Target Pocket ComponentSection Version 2015-12-12 11:54:14 EST Superseded Xenial release mainlibs 1.0.18-4ubuntu1 2015-12-13 13:10:09 EST Deleted Xenial proposedmainlibs 1.0.18-4ubuntu1 # Approved upload: [ubuntu/xenial-proposed] libmemcached 1.0.18-4.1ubuntu2 (Waiting for approval) -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1573594 Title: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling Status in libmemcached: New Status in libmemcached package in Ubuntu: Fix Released Status in libmemcached source package in Trusty: In Progress Status in libmemcached source package in Xenial: In Progress Status in libmemcached source package in Bionic: In Progress Status in libmemcached source package in Cosmic: In Progress Status in libmemcached source package in Disco: Fix Released Status in libmemcached package in Debian: New Bug description: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start [Test Case] This bug is difficult to reproduce since it depends on the contents of the stack. However, here is a test case using the fix on Bionic that shows that this fix does not cause any problems. For testing you need 1) A memcached server. You can setup one by following the instructions in [1], or (what I did) create one in the cloud [2]. 2) A client test program to connect to the memcached server. One can be found in [3]. This simple test connects to a memcache server and test basic get/set operations. Copy paste the C code into a file (sals_test.c) and compile with : gcc -o sasl_test -O2 sasl_test.c -lmemcached -pthread 3) On a machine with the updated version of libmemcached in which the fix is applied : jo@bionic-vm:~$ dpkg -l | grep libmemcached ii libhashkit-dev:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms (development files) ii libhashkit2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms ii libmemcached-dbg:amd641.0.18-4.2ubuntu0.18.04.1 amd64Debug Symbols for libmemcached ii libmemcached-dev:amd641.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server (development files) ii libmemcached-tools1.0.18-4.2ubuntu0.18.04.1 amd64Commandline tools for talking to memcached via libmemcached ii libmemcached11:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server ii libmemcachedutil2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64library implementing connection pooling for libmemcached Run the sals_test binary : #./sasl_test [username] [password] [server] In my case using the credentials and the server created in step 1 : jo@bionic-vm:~$ ./sasl_test 88BAB0 1A99094B77C8935ED9F1461C767DB1F9 mc2.dev.eu.ec2.memcachier.com Get/Set success! [1] https://blog.couchbase.com/sasl-memcached-now-available/ [2] https://www.memcachier.com/ [3]
[Sts-sponsors] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
This bug was fixed in the package libmemcached - 1.0.18-4.2ubuntu1 --- libmemcached (1.0.18-4.2ubuntu1) disco; urgency=medium * d/p/fixing_missing_null_termination.patch: - Fix missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling (LP: #1573594) -- Ioanna Alifieraki Fri, 18 Jan 2019 13:04:25 + ** Changed in: libmemcached (Ubuntu Disco) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1573594 Title: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling Status in libmemcached: New Status in libmemcached package in Ubuntu: Fix Released Status in libmemcached source package in Trusty: In Progress Status in libmemcached source package in Xenial: In Progress Status in libmemcached source package in Bionic: In Progress Status in libmemcached source package in Cosmic: In Progress Status in libmemcached source package in Disco: Fix Released Status in libmemcached package in Debian: New Bug description: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start [Test Case] This bug is difficult to reproduce since it depends on the contents of the stack. However, here is a test case using the fix on Bionic that shows that this fix does not cause any problems. For testing you need 1) A memcached server. You can setup one by following the instructions in [1], or (what I did) create one in the cloud [2]. 2) A client test program to connect to the memcached server. One can be found in [3]. This simple test connects to a memcache server and test basic get/set operations. Copy paste the C code into a file (sals_test.c) and compile with : gcc -o sasl_test -O2 sasl_test.c -lmemcached -pthread 3) On a machine with the updated version of libmemcached in which the fix is applied : jo@bionic-vm:~$ dpkg -l | grep libmemcached ii libhashkit-dev:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms (development files) ii libhashkit2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms ii libmemcached-dbg:amd641.0.18-4.2ubuntu0.18.04.1 amd64Debug Symbols for libmemcached ii libmemcached-dev:amd641.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server (development files) ii libmemcached-tools1.0.18-4.2ubuntu0.18.04.1 amd64Commandline tools for talking to memcached via libmemcached ii libmemcached11:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server ii libmemcachedutil2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64library implementing connection pooling for libmemcached Run the sals_test binary : #./sasl_test [username] [password] [server] In my case using the credentials and the server created in step 1 : jo@bionic-vm:~$ ./sasl_test 88BAB0 1A99094B77C8935ED9F1461C767DB1F9 mc2.dev.eu.ec2.memcachier.com Get/Set success! [1] https://blog.couchbase.com/sasl-memcached-now-available/ [2] https://www.memcachier.com/ [3] https://blog.memcachier.com/2014/11/05/ubuntu-libmemcached-and-sasl-support/ [Regression Potential] This fix initialises the buffer to 0. Any potential regression may include failure of the authentication when using SASL. [Other Info] This bug affects trusty and later. * rmadison: libmemcached | 1.0.8-1ubuntu2 | trusty | source libmemcached | 1.0.18-4.1 | xenial | source libmemcached | 1.0.18-4.2 | bionic | source libmemcached | 1.0.18-4.2 | cosmic | source libmemcached | 1.0.18-4.2 | disco | source * Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919696 * Upstream seems pretty quiet since 2014
[Sts-sponsors] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
** Description changed: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start + [Test Case] - There is no known reliable reproducer. + This bug is difficult to reproduce since it depends on the contents of the stack. + However, here is a test case using the fix on Bionic that shows that this fix does not cause any problems. + + For testing you need + + 1) A memcached server. +You can setup one by following the instructions in [1], +or (what I did) create one in the cloud [2]. + + 2) A client test program to connect to the memcached server. +One can be found in [3]. +This simple test connects to a memcache server and test basic get/set operations. +Copy paste the C code into a file (sals_test.c) and compile with : +gcc -o sasl_test -O2 sasl_test.c -lmemcached -pthread + + 3) On a machine with the updated version of libmemcached in which the fix is applied : +jo@bionic-vm:~$ dpkg -l | grep libmemcached + ii libhashkit-dev:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms (development files) + ii libhashkit2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms + ii libmemcached-dbg:amd641.0.18-4.2ubuntu0.18.04.1 amd64Debug Symbols for libmemcached + ii libmemcached-dev:amd641.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server (development files) + ii libmemcached-tools1.0.18-4.2ubuntu0.18.04.1 amd64Commandline tools for talking to memcached via libmemcached + ii libmemcached11:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server + ii libmemcachedutil2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64library implementing connection pooling for libmemcached + +Run the sals_test binary : +#./sasl_test [username] [password] [server] + +In my case using the credentials and the server created in step 1 : +jo@bionic-vm:~$ ./sasl_test 88BAB0 1A99094B77C8935ED9F1461C767DB1F9 mc2.dev.eu.ec2.memcachier.com +Get/Set success! + + [1] https://blog.couchbase.com/sasl-memcached-now-available/ + [2] https://www.memcachier.com/ + [3] https://blog.memcachier.com/2014/11/05/ubuntu-libmemcached-and-sasl-support/ [Regression Potential] This fix initialises the buffer to 0. Any potential regression may include failure of the authentication when using SASL. [Other Info] This bug affects trusty and later. * rmadison: - libmemcached | 1.0.8-1ubuntu2 | trusty | source - libmemcached | 1.0.18-4.1 | xenial | source - libmemcached | 1.0.18-4.2 | bionic | source - libmemcached | 1.0.18-4.2 | cosmic | source - libmemcached | 1.0.18-4.2 | disco | source + libmemcached | 1.0.8-1ubuntu2 | trusty | source + libmemcached | 1.0.18-4.1 | xenial | source + libmemcached | 1.0.18-4.2 | bionic | source + libmemcached | 1.0.18-4.2 | cosmic | source + libmemcached | 1.0.18-4.2 | disco | source * Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919696 * Upstream seems pretty quiet since 2014 Unfortunately, because the project seems more or less dead ... it seems like we won't be able submit anything upstream and go straight to fixing Debian and Ubuntu. - - Repo: + - Repo: bzr branch lp:libmemcached - Last commit: revno: 1113 [merge] committer: Continuous Integration branch nick: workspace timestamp: Sun 2014-02-16 03:31:37 -0800 message: Merge bzr://soup.haus/ Build: jenkins-Libmemcached-473 -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1573594 Title: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling Status in libmemcached: New Status in libmemcached package in Ubuntu: In Progress Status in libmemcached source
[Sts-sponsors] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
** Changed in: libmemcached (Debian) Status: Unknown => New -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1573594 Title: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling Status in libmemcached: New Status in libmemcached package in Ubuntu: In Progress Status in libmemcached source package in Trusty: In Progress Status in libmemcached source package in Xenial: In Progress Status in libmemcached source package in Bionic: In Progress Status in libmemcached source package in Cosmic: In Progress Status in libmemcached source package in Disco: In Progress Status in libmemcached package in Debian: New Bug description: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start [Test Case] There is no known reliable reproducer. [Regression Potential] This fix initialises the buffer to 0. Any potential regression may include failure of the authentication when using SASL. [Other Info] This bug affects trusty and later. * rmadison: libmemcached | 1.0.8-1ubuntu2 | trusty | source libmemcached | 1.0.18-4.1 | xenial | source libmemcached | 1.0.18-4.2 | bionic | source libmemcached | 1.0.18-4.2 | cosmic | source libmemcached | 1.0.18-4.2 | disco | source * Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919696 * Upstream seems pretty quiet since 2014 Unfortunately, because the project seems more or less dead ... it seems like we won't be able submit anything upstream and go straight to fixing Debian and Ubuntu. - Repo: bzr branch lp:libmemcached - Last commit: revno: 1113 [merge] committer: Continuous Integration branch nick: workspace timestamp: Sun 2014-02-16 03:31:37 -0800 message: Merge bzr://soup.haus/ Build: jenkins-Libmemcached-473 To manage notifications about this bug go to: https://bugs.launchpad.net/libmemcached/+bug/1573594/+subscriptions -- Mailing list: https://launchpad.net/~sts-sponsors Post to : sts-sponsors@lists.launchpad.net Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
[Sts-sponsors] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
@joalif, I'll gladly sponsor this SRU for you ... but I'm a little bit concerned about the test case field being empty and I'm sure the SRU team (ppl who approved upload) will do as well. While I can understand there is no clear reproducer for that bug ... Could you please prove somehow that you did some dogfooding ? Use libmemcached in a context as close as possible to the modified code ? Ran a libmemcached/memcached test suite (if any) ? Anything that can bring confidence in this patch. Especially that we have no upstream maintainer to review/accept it. Regards, Eric ** Description changed: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start [Test Case] There is no known reliable reproducer. [Regression Potential] This fix initialises the buffer to 0. Any potential regression may include failure of the authentication when using SASL. [Other Info] This bug affects trusty and later. + * rmadison: + libmemcached | 1.0.8-1ubuntu2 | trusty | source + libmemcached | 1.0.18-4.1 | xenial | source + libmemcached | 1.0.18-4.2 | bionic | source + libmemcached | 1.0.18-4.2 | cosmic | source + libmemcached | 1.0.18-4.2 | disco | source + * Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919696 * Upstream seems pretty quiet since 2014 - Repo: bzr branch lp:libmemcached + Unfortunately, because the project seems more or less dead ... it seems + like we won't be able submit anything upstream and go straight to fixing + Debian and Ubuntu. - Last commit: + - Repo: + bzr branch lp:libmemcached + + - Last commit: revno: 1113 [merge] committer: Continuous Integration branch nick: workspace timestamp: Sun 2014-02-16 03:31:37 -0800 message: - Merge bzr://soup.haus/ Build: jenkins-Libmemcached-473 - - Unfortunately, because the project seems more or less dead ... it seems - like we won't be able submit anything upstream and go straight by fixing - Debian and Ubuntu. + Merge bzr://soup.haus/ Build: jenkins-Libmemcached-473 -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1573594 Title: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling Status in libmemcached: New Status in libmemcached package in Ubuntu: In Progress Status in libmemcached source package in Trusty: In Progress Status in libmemcached source package in Xenial: In Progress Status in libmemcached source package in Bionic: In Progress Status in libmemcached source package in Cosmic: In Progress Status in libmemcached source package in Disco: In Progress Status in libmemcached package in Debian: Unknown Bug description: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start [Test Case] There is no known reliable reproducer. [Regression Potential] This fix initialises the buffer to 0. Any potential regression may include failure of the authentication when using SASL. [Other Info] This bug affects trusty and later. * rmadison: libmemcached | 1.0.8-1ubuntu2 | trusty | source libmemcached | 1.0.18-4.1 | xenial | source libmemcached | 1.0.18-4.2 | bionic | source libmemcached | 1.0.18-4.2 | cosmic | source libmemcached | 1.0.18-4.2 | disco | source
[Sts-sponsors] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
** Bug watch added: Debian Bug tracker #919696 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919696 ** Also affects: libmemcached (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919696 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1573594 Title: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling Status in libmemcached: New Status in libmemcached package in Ubuntu: In Progress Status in libmemcached source package in Trusty: In Progress Status in libmemcached source package in Xenial: In Progress Status in libmemcached source package in Bionic: In Progress Status in libmemcached source package in Cosmic: In Progress Status in libmemcached source package in Disco: In Progress Status in libmemcached package in Debian: Unknown Bug description: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start [Test Case] There is no known reliable reproducer. [Regression Potential] This fix initialises the buffer to 0. Any potential regression may include failure of the authentication when using SASL. [Other Info] This bug affects trusty and later. * rmadison: libmemcached | 1.0.8-1ubuntu2 | trusty | source libmemcached | 1.0.18-4.1 | xenial | source libmemcached | 1.0.18-4.2 | bionic | source libmemcached | 1.0.18-4.2 | cosmic | source libmemcached | 1.0.18-4.2 | disco | source * Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919696 * Upstream seems pretty quiet since 2014 Unfortunately, because the project seems more or less dead ... it seems like we won't be able submit anything upstream and go straight to fixing Debian and Ubuntu. - Repo: bzr branch lp:libmemcached - Last commit: revno: 1113 [merge] committer: Continuous Integration branch nick: workspace timestamp: Sun 2014-02-16 03:31:37 -0800 message: Merge bzr://soup.haus/ Build: jenkins-Libmemcached-473 To manage notifications about this bug go to: https://bugs.launchpad.net/libmemcached/+bug/1573594/+subscriptions -- Mailing list: https://launchpad.net/~sts-sponsors Post to : sts-sponsors@lists.launchpad.net Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
[Sts-sponsors] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
** Description changed: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start - [Test Case] There is no known reliable reproducer. - [Regression Potential] This fix initialises the buffer to 0. Any potential regression may include failure of the authentication when using SASL. - [Other Info] This bug affects trusty and later. + + * Debian bug: + https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919696 + + * Upstream seems pretty quiet since 2014 + + Repo: bzr branch lp:libmemcached + + Last commit: + revno: 1113 [merge] + committer: Continuous Integration + branch nick: workspace + timestamp: Sun 2014-02-16 03:31:37 -0800 + message: + Merge bzr://soup.haus/ Build: jenkins-Libmemcached-473 + + Unfortunately, because the project seems more or less dead ... it seems + like we won't be able submit anything upstream and go straight by fixing + Debian and Ubuntu. -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1573594 Title: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling Status in libmemcached: New Status in libmemcached package in Ubuntu: In Progress Status in libmemcached source package in Trusty: In Progress Status in libmemcached source package in Xenial: In Progress Status in libmemcached source package in Bionic: In Progress Status in libmemcached source package in Cosmic: In Progress Status in libmemcached source package in Disco: In Progress Status in libmemcached package in Debian: Unknown Bug description: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start [Test Case] There is no known reliable reproducer. [Regression Potential] This fix initialises the buffer to 0. Any potential regression may include failure of the authentication when using SASL. [Other Info] This bug affects trusty and later. * Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919696 * Upstream seems pretty quiet since 2014 Repo: bzr branch lp:libmemcached Last commit: revno: 1113 [merge] committer: Continuous Integration branch nick: workspace timestamp: Sun 2014-02-16 03:31:37 -0800 message: Merge bzr://soup.haus/ Build: jenkins-Libmemcached-473 Unfortunately, because the project seems more or less dead ... it seems like we won't be able submit anything upstream and go straight by fixing Debian and Ubuntu. To manage notifications about this bug go to: https://bugs.launchpad.net/libmemcached/+bug/1573594/+subscriptions -- Mailing list: https://launchpad.net/~sts-sponsors Post to : sts-sponsors@lists.launchpad.net Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
[Sts-sponsors] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
** Tags removed: sts-sponsor-ddstreet ** Tags added: sts-sponsor-slashd -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1573594 Title: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling Status in libmemcached: New Status in libmemcached package in Ubuntu: In Progress Status in libmemcached source package in Trusty: In Progress Status in libmemcached source package in Xenial: In Progress Status in libmemcached source package in Bionic: In Progress Status in libmemcached source package in Cosmic: In Progress Status in libmemcached source package in Disco: In Progress Bug description: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start [Test Case] There is no known reliable reproducer. [Regression Potential] This fix initialises the buffer to 0. Any potential regression may include failure of the authentication when using SASL. [Other Info] This bug affects trusty and later. * Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919696 * Upstream seems pretty quiet since 2014 Repo: bzr branch lp:libmemcached Last commit: revno: 1113 [merge] committer: Continuous Integration branch nick: workspace timestamp: Sun 2014-02-16 03:31:37 -0800 message: Merge bzr://soup.haus/ Build: jenkins-Libmemcached-473 Unfortunately, because the project seems more or less dead ... it seems like we won't be able submit anything upstream and go straight by fixing Debian and Ubuntu. To manage notifications about this bug go to: https://bugs.launchpad.net/libmemcached/+bug/1573594/+subscriptions -- Mailing list: https://launchpad.net/~sts-sponsors Post to : sts-sponsors@lists.launchpad.net Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
[Sts-sponsors] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
New debdiff for xenial. ** Patch added: "lp1573594_xenial.debdiff" https://bugs.launchpad.net/ubuntu/+source/libmemcached/+bug/1573594/+attachment/5230344/+files/lp1573594_xenial.debdiff -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1573594 Title: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling Status in libmemcached: New Status in libmemcached package in Ubuntu: In Progress Status in libmemcached source package in Trusty: In Progress Status in libmemcached source package in Xenial: In Progress Status in libmemcached source package in Bionic: In Progress Status in libmemcached source package in Cosmic: In Progress Status in libmemcached source package in Disco: In Progress Bug description: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start [Test Case] There is no known reliable reproducer. [Regression Potential] This fix initialises the buffer to 0. Any potential regression may include failure of the authentication when using SASL. [Other Info] This bug affects trusty and later. To manage notifications about this bug go to: https://bugs.launchpad.net/libmemcached/+bug/1573594/+subscriptions -- Mailing list: https://launchpad.net/~sts-sponsors Post to : sts-sponsors@lists.launchpad.net Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
[Sts-sponsors] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
New debdiff for disco. ** Patch added: "lp1573594_disco.debdiff" https://bugs.launchpad.net/ubuntu/+source/libmemcached/+bug/1573594/+attachment/5230340/+files/lp1573594_disco.debdiff -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1573594 Title: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling Status in libmemcached: New Status in libmemcached package in Ubuntu: In Progress Status in libmemcached source package in Trusty: In Progress Status in libmemcached source package in Xenial: In Progress Status in libmemcached source package in Bionic: In Progress Status in libmemcached source package in Cosmic: In Progress Status in libmemcached source package in Disco: In Progress Bug description: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start [Test Case] There is no known reliable reproducer. [Regression Potential] This fix initialises the buffer to 0. Any potential regression may include failure of the authentication when using SASL. [Other Info] This bug affects trusty and later. To manage notifications about this bug go to: https://bugs.launchpad.net/libmemcached/+bug/1573594/+subscriptions -- Mailing list: https://launchpad.net/~sts-sponsors Post to : sts-sponsors@lists.launchpad.net Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
[Sts-sponsors] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
** Patch added: "lp1573594_trusty.debdiff" https://bugs.launchpad.net/ubuntu/+source/libmemcached/+bug/1573594/+attachment/5230346/+files/lp1573594_trusty.debdiff -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1573594 Title: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling Status in libmemcached: New Status in libmemcached package in Ubuntu: In Progress Status in libmemcached source package in Trusty: In Progress Status in libmemcached source package in Xenial: In Progress Status in libmemcached source package in Bionic: In Progress Status in libmemcached source package in Cosmic: In Progress Status in libmemcached source package in Disco: In Progress Bug description: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start [Test Case] There is no known reliable reproducer. [Regression Potential] This fix initialises the buffer to 0. Any potential regression may include failure of the authentication when using SASL. [Other Info] This bug affects trusty and later. To manage notifications about this bug go to: https://bugs.launchpad.net/libmemcached/+bug/1573594/+subscriptions -- Mailing list: https://launchpad.net/~sts-sponsors Post to : sts-sponsors@lists.launchpad.net Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
[Sts-sponsors] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
New debdiff for bionic. ** Patch added: "lp1573594_bionic.debdiff" https://bugs.launchpad.net/ubuntu/+source/libmemcached/+bug/1573594/+attachment/5230342/+files/lp1573594_bionic.debdiff -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1573594 Title: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling Status in libmemcached: New Status in libmemcached package in Ubuntu: In Progress Status in libmemcached source package in Trusty: In Progress Status in libmemcached source package in Xenial: In Progress Status in libmemcached source package in Bionic: In Progress Status in libmemcached source package in Cosmic: In Progress Status in libmemcached source package in Disco: In Progress Bug description: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start [Test Case] There is no known reliable reproducer. [Regression Potential] This fix initialises the buffer to 0. Any potential regression may include failure of the authentication when using SASL. [Other Info] This bug affects trusty and later. To manage notifications about this bug go to: https://bugs.launchpad.net/libmemcached/+bug/1573594/+subscriptions -- Mailing list: https://launchpad.net/~sts-sponsors Post to : sts-sponsors@lists.launchpad.net Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
[Sts-sponsors] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
New debdiff for bionic. ** Patch added: "lp1573594_bionic.debdiff" https://bugs.launchpad.net/ubuntu/+source/libmemcached/+bug/1573594/+attachment/5230343/+files/lp1573594_bionic.debdiff -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1573594 Title: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling Status in libmemcached: New Status in libmemcached package in Ubuntu: In Progress Status in libmemcached source package in Trusty: In Progress Status in libmemcached source package in Xenial: In Progress Status in libmemcached source package in Bionic: In Progress Status in libmemcached source package in Cosmic: In Progress Status in libmemcached source package in Disco: In Progress Bug description: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start [Test Case] There is no known reliable reproducer. [Regression Potential] This fix initialises the buffer to 0. Any potential regression may include failure of the authentication when using SASL. [Other Info] This bug affects trusty and later. To manage notifications about this bug go to: https://bugs.launchpad.net/libmemcached/+bug/1573594/+subscriptions -- Mailing list: https://launchpad.net/~sts-sponsors Post to : sts-sponsors@lists.launchpad.net Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
[Sts-sponsors] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
** Patch added: "lp1573594_cosmic.debdiff" https://bugs.launchpad.net/ubuntu/+source/libmemcached/+bug/1573594/+attachment/5230341/+files/lp1573594_cosmic.debdiff -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1573594 Title: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling Status in libmemcached: New Status in libmemcached package in Ubuntu: In Progress Status in libmemcached source package in Trusty: In Progress Status in libmemcached source package in Xenial: In Progress Status in libmemcached source package in Bionic: In Progress Status in libmemcached source package in Cosmic: In Progress Status in libmemcached source package in Disco: In Progress Bug description: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start [Test Case] There is no known reliable reproducer. [Regression Potential] This fix initialises the buffer to 0. Any potential regression may include failure of the authentication when using SASL. [Other Info] This bug affects trusty and later. To manage notifications about this bug go to: https://bugs.launchpad.net/libmemcached/+bug/1573594/+subscriptions -- Mailing list: https://launchpad.net/~sts-sponsors Post to : sts-sponsors@lists.launchpad.net Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
[Sts-sponsors] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
Hi @joalif, couple changes needed in the debdiffs, please: 1) the patch "debian/patches/fix_missing_null_termination" has no suffix... not a major problem but convention is to suffix it with ".diff" or ".patch" 2) The line in your patch: + * Fix missing null terminated buffer. Closes: #853497. should be removed; the text is redundant with the line above it, and the patch doesn't actually fix Debian bug 853497 (as far as I can tell, at least). Also, Ubuntu debdiffs shouldn't include Debian-specific Closes: tags...which leads to: 3) Your changelog entry contains "(Closes: #1573594)", but Ubuntu uses "(LP: #NN)" tag formatting. Please change your changelog entry to include "(LP: #1573594)" instead. 4) All your debdiffs include the same package version: 1.0.18-4.2ubuntu1 This is a tricky point of pkg versioning; since they are currently identical in multiple releases, it's best to use a release-specific version number for each of the SRU releases, and only use the "ubuntu1" suffix for the development (i.e. disco) release. Specifically to clarify: releasecurrent version new version Xenial 1.0.18-4.11.0.18-4.1ubuntu1 Bionic 1.0.18-4.21.0.18-4.2ubuntu0.18.04.1 Cosmic 1.0.18-4.21.0.18-4.2ubuntu0.18.10.1 Disco 1.0.18-4.21.0.18-4.2ubuntu1 I can make the changes to the debdiffs you already uploaded if you want, or please upload new debdiffs with the recommended changes. Thanks! ** Tags removed: sts-sponsor ** Tags added: sts-sponsor-ddstreet -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1573594 Title: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling Status in libmemcached: New Status in libmemcached package in Ubuntu: In Progress Status in libmemcached source package in Trusty: In Progress Status in libmemcached source package in Xenial: In Progress Status in libmemcached source package in Bionic: In Progress Status in libmemcached source package in Cosmic: In Progress Status in libmemcached source package in Disco: In Progress Bug description: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start [Test Case] There is no known reliable reproducer. [Regression Potential] This fix initialises the buffer to 0. Any potential regression may include failure of the authentication when using SASL. [Other Info] This bug affects trusty and later. To manage notifications about this bug go to: https://bugs.launchpad.net/libmemcached/+bug/1573594/+subscriptions -- Mailing list: https://launchpad.net/~sts-sponsors Post to : sts-sponsors@lists.launchpad.net Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
[Sts-sponsors] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
The attachment "lp1573594_disco.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team. [This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.] ** Tags added: patch -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1573594 Title: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling Status in libmemcached: New Status in libmemcached package in Ubuntu: In Progress Status in libmemcached source package in Trusty: In Progress Status in libmemcached source package in Xenial: In Progress Status in libmemcached source package in Bionic: In Progress Status in libmemcached source package in Cosmic: In Progress Status in libmemcached source package in Disco: In Progress Bug description: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start [Test Case] There is no known reliable reproducer. [Regression Potential] This fix initialises the buffer to 0. Any potential regression may include failure of the authentication when using SASL. [Other Info] This bug affects trusty and later. To manage notifications about this bug go to: https://bugs.launchpad.net/libmemcached/+bug/1573594/+subscriptions -- Mailing list: https://launchpad.net/~sts-sponsors Post to : sts-sponsors@lists.launchpad.net Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
