[Sts-sponsors] [Bug 1812760] Re: networkd: [Route] PreferredSource not working in *.network files
** Bug watch added: github.com/systemd/systemd/issues #5882 https://github.com/systemd/systemd/issues/5882 ** Also affects: systemd via https://github.com/systemd/systemd/issues/5882 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/1812760 Title: networkd: [Route] PreferredSource not working in *.network files Status in systemd: Unknown Status in systemd package in Ubuntu: In Progress Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: In Progress Bug description: [Impact] Users cannot create IPv6 routes that specify PreferredSource. This means that users cannot specify a number of valid IPv6 routes that are useful in some circumstances. These routes can be created with the 'ip' tool, just not with systemd. This was reported upstream in systemd issue #5882 is fixed by pulling in the changes in systemd PR #11375 - https://github.com/systemd/systemd/pull/11375 [Test Case] Start a Bionic or Cosmic VM. Add the following netplan yaml (adjust for ethernet card and MAC): network: version: 2 ethernets: ens3: dhcp4: true match: macaddress: 52:54:00:e2:c2:d7 set-name: ens3 addresses: ["fd8f:1d7d:b141::2/64", "fd8f:1d7d:b141::200/64"] routes: - to: "a::/16" via: "fd8f:1d7d:b141::1" from: "fd8f:1d7d:b141::2" - to: "fd8f:1d7d:b141::/64" scope: link from: "fd8f:1d7d:b141::2" metric: 255 Run netplan apply or reboot. Wait ~10s. Currently, ip -6 route will not include a route to "a::/16", and will not include the route to "fd8f:1d7d:b141::/64" that has "fd8f:1d7d:b141::2" as the source address - both those addresses will be missing. Correct behaviour is for ip -6 route to report the following: ubuntu@b-np:~$ ip -6 route a::/16 via fd8f:1d7d:b141::1 dev ens3 proto static src fd8f:1d7d:b141::2 metric 1024 pref medium fd8f:1d7d:b141::/64 dev ens3 proto static src fd8f:1d7d:b141::2 metric 255 pref medium fd8f:1d7d:b141::/64 dev ens3 proto kernel metric 256 pref medium fe80::/64 dev ens3 proto kernel metric 256 pref medium [Regression Potential] This changes the state machine in systemd which configures the links. It passes systemd's internal tests, and has been approved by systemd maintainers, but it remains possible that the changes will break the configuration of obscure network setups. The backport requires pulling in two further commits that also change behaviour: currently systemd deletes all addresses and routes that were attached to an interface. With this change, it will only delete those that are not specified in the configuration files. I do not know how this could cause issues - it moves from a surprising behaviour to a less surprising behaviour, but it's worth pointing out. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1812760/+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
[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] https://blog.memcachier.com/2014/11/05/ubuntu-libmemca
[Sts-sponsors] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
Note: --- * No longer active upstream - https://code.launchpad.net/libmemcached - Last Modified: 2014-02-16 * Patch has been submitted Debian - https://bugs.debian.org/919696 --- Under the circumstances of libmemcached being no longer active upstream and considering the fact that @Joalif filed a bug and submitted the patch to Debian: Sponsored for C/B/X/T. @Joalif, when the releases will turn "Fix Committed". The package will start building and soon be found in $release-proposed for the testing phase. Please test and describe (with details) your tests and results against each libmemcached proposed packages. It will serves as a justification for the SRU team to approve the final copy from -proposed to -updates (final destination marking the end of the SRU) if no regression found. Regards, 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: 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