sts-sponsors team mailing list archive

[Eric Desrochers <eric.desrochers@xxxxxxxxxxxxx>]

@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 <ci@xxxxxxxxxxx>
  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

  * 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 <ci@xxxxxxxxxxx>
  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