CVE-2016-9877 RabbitMQ authentication vulnerability

Bug #1706900 reported by Nils Toedtmann on 2017-07-27
256
This bug affects 1 person
Affects Status Importance Assigned to Milestone
RabbitMQ
Fix Released
Unknown
rabbitmq-server (Ubuntu)
Medium
Unassigned
Trusty
High
Marc Deslauriers
Xenial
High
Marc Deslauriers

Bug Description

https://pivotal.io/security/cve-2016-9877

  "MQTT (MQ Telemetry Transport) connection authentication with a username/password pair succeeds if an existing username is provided but the password is omitted from the connection request. Connections that use TLS with a client-provided certificate are not affected."

Affects RabbitMQ "3.x versions prior to 3.5.8"

Ubuntu's Xenial repos are currently offering 3.5.7-1ubuntu0.16.04.1, and according to its changelog, Pivotal's fix for CVE-2016-9877 has not been included.

CVE References

information type: Private Security → Public Security
Changed in rabbitmq:
status: Unknown → Fix Released
Tyler Hicks (tyhicks) wrote :

Hello and thanks for the bug report! We are aware of this issue and are tracking in the Ubuntu CVE Tracker:

  https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-9877.html

Changed in rabbitmq-server (Ubuntu):
importance: Undecided → Medium
status: New → Triaged

Please bump the importance to "High". This is a trivially and remotely exploitable authentication bypass, and it's classified "Critical" upstream, and "High" over at Debian.

This bug was raised and fixed upstream last year. Debian backported the fix in January. Since when are you aware of it?

Changed in rabbitmq-server (Ubuntu):
status: Triaged → Fix Released
Changed in rabbitmq-server (Ubuntu Trusty):
status: New → Confirmed
Changed in rabbitmq-server (Ubuntu Xenial):
status: New → Confirmed
Changed in rabbitmq-server (Ubuntu Trusty):
importance: Undecided → High
Changed in rabbitmq-server (Ubuntu Xenial):
importance: Undecided → High
Changed in rabbitmq-server (Ubuntu Trusty):
assignee: nobody → Marc Deslauriers (mdeslaur)
Changed in rabbitmq-server (Ubuntu Xenial):
assignee: nobody → Marc Deslauriers (mdeslaur)
Marc Deslauriers (mdeslaur) wrote :

Packages are building in the security team PPA here:

https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages

They will be released as security updates next week once they have passed QA.

Thanks.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package rabbitmq-server - 3.5.7-1ubuntu0.16.04.2

---------------
rabbitmq-server (3.5.7-1ubuntu0.16.04.2) xenial-security; urgency=medium

  * SECURITY UPDATE: authentication bypass (LP: #1706900)
    - debian/patches/CVE-2016-9877.patch: fix password check in
      plugins-src/rabbitmq-mqtt/src/rabbit_mqtt_processor.erl, add test to
      plugins-src/rabbitmq-mqtt/test/src/com/rabbitmq/mqtt/test/MqttTest.java,
      fix URL in plugins-src/rabbitmq-mqtt/test/Makefile.
    - CVE-2016-9877

 -- Marc Deslauriers <email address hidden> Thu, 27 Jul 2017 14:36:17 -0400

Changed in rabbitmq-server (Ubuntu Xenial):
status: Confirmed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package rabbitmq-server - 3.2.4-1ubuntu0.1

---------------
rabbitmq-server (3.2.4-1ubuntu0.1) trusty-security; urgency=medium

  * SECURITY UPDATE: authentication bypass (LP: #1706900)
    - debian/patches/CVE-2016-9877.patch: fix password check in
      plugins-src/rabbitmq-mqtt/src/rabbit_mqtt_processor.erl, add test to
      plugins-src/rabbitmq-mqtt/test/src/com/rabbitmq/mqtt/test/MqttTest.java,
      fix URL in plugins-src/rabbitmq-mqtt/test/Makefile.
    - CVE-2016-9877

 -- Marc Deslauriers <email address hidden> Thu, 27 Jul 2017 14:48:35 -0400

Changed in rabbitmq-server (Ubuntu Trusty):
status: Confirmed → Fix Released

Thanks for fixing so quickly once this ticket was raised!

I have questions though about the time before.

rabbitmq-server is in the Canonical-supported 'main' repo of two active Ubuntu LTS releases. In Dec 2016, a security issue and a patch are published upstream, rated 'critical'. Debian rates it as 'high' and releases updates within a month. At some point in time (I can't way when), the issue appears in Ubuntu's CVE tracker (see above) and gets marked 'medium'. Other than that, nothing happens at Ubuntu until a random user (me) stumbles upon it and files this very bug report.

- Why was this bug rated lower than upstream ('medium' rather than 'critical')?
- What is the CVE tracker for, if not triggering the process leading to security updates where necessary?
- Are there targets defined/documented somewhere, how quickly upstream security patches ought to be integrated into 'main' LTS packages?
- Assuming we agree that 7 month is too long (right?), what is being done to make sure those targets are met?

Seth Arnold (seth-arnold) wrote :

Hi Nils,

Ubuntu's security team does not use upstream assessments of
severity when assigning priorities. Our criteria are enumerated at
http://bazaar.launchpad.net/~ubuntu-security/ubuntu-cve-tracker/master/view/head:/README#L191 .

Upstream estimates of severity are usually focused strictly on the
service at hand while we need to prioritize our work across more than
ten thousand sources. This doesn't mean upstream severities are wrong,
but we must have some way to prioritize our work that's consistent.

The CVE tracker does indeed trigger the process to issuing security
updates. You can see this process at https://usn.ubuntu.com/usn/ where
we have issued 290 USNs so far this year. Less visible is the sponsored
updates to universe packages in collaboration with the community, which
do not get USNs.

We do not have service level agreements for security updates. Even
if such a thing were feasible for our team we believe this would be
counter-productive to overall security as many upstreams issue regression
fixes after security fixes get wider coverage.

Seven months for an issue with an upstream-provided patch is indeed too
long. We have recently hired a new team member; while his duties are
primarily providing extended support for 12.04 LTS to Ubuntu Advantage
customers, he will also perform additional updates and generalist duties
as time allows.

In addition, while it doesn't happen often, we are happy to sponsor
updates for packages in main. It would probably be best to check in with
us before beginning work on a sponsored update to ensure (a) we'd be
interested in the approach (b) that it wouldn't be duplicating work. For
more information see https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures
. This may help bring a specific update to our users more quickly.

Thanks

To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.