[Sts-sponsors] [Bug 1812760] Re: networkd: [Route] PreferredSource not working in *.network files

2019-01-25 Thread Dan Streetman
** 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

2019-01-25 Thread Eric Desrochers
[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]