EVAL Lua Sandbox Escape (CVE-2015-4335 / DSA-3279)

[James]

This is a vulnerability that has been fixed upstream in v2.8.21 and v3.0.2, but Trusty is still shipping 2.8.4-2 with no mention of this bug being fixed in the changelog.

The vuln was announced at http://benmmurphy.github.io/blog/2015/06/04/redis-eval-lua-sandbox-escape/ and has some more info here https://redislabs.com/blog/cve-2015-4335-dsa-3279-redis-lua-sandbox-escape

Sorry if this isn't the right place to report this, I couldn't really find a better way to report it.

I doubt you really need this additional information considering there is a CVE and DSAreleased for this and its already been fixed upstream, but just so I don't get auto-filtered..

$ lsb_release -rd
Description: Ubuntu 14.04.2 LTS
Release: 14.04
$ apt-cache policy redis-server
redis-server:
  Installed: 2:2.8.4-2
  Candidate: 2:2.8.4-2
  Version table:
 *** 2:2.8.4-2 0
        500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu/ trusty/universe amd64 Packages
        100 /var/lib/dpkg/status
what I expected to happen: run apt-get update && apt-get upgrade, no longer be vulnerable to a sandbox escape exploit
what happened instead: updated package is nowhere to be found.

[Steve Beattie (sbeattie)]

Thanks for taking the time to report this bug and helping to make Ubuntu better. Since the package referred to in this bug is in universe or multiverse, it is community maintained. If you are able, I suggest coordinating with upstream and posting a debdiff for this issue. When a debdiff is available, members of the security team will review it and publish the package. See the following link for more information: https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures

[Launchpad Janitor (janitor)]

[Expired for redis (Ubuntu) because there has been no activity for 60 days.]

[Jeff Cook (jeff.cook.wildworks)]

I've attached a debdiff that upgrades the package from 2.8.4, released in Jan 2014, to 2.8.24, which was released in Dec 2015.

The most crucial change is the critical fix for the CVE mentioned in this thread, which was introduced in redis 2.8.21. Between 2.8.4 and 2.8.24, 6 updates are marked CRITICAL urgency and 12 updates are marked HIGH urgency.

These versions appear to be compatible except for a minor API modification introduced in 2.8.14: "* [NEW] **WARNING, minor API change**: PUBSUB NUMSUB: return type modified to integer. (Matt Stancliff)" Debian has included this change in their stable updates, however.

The dependecy on jemalloc was upgraded to jemalloc 3.6.0 as of redis 2.8.12. It is probably wise to sync down jemalloc 3.6.0 from Debian jessie: https://packages.debian.org/source/jessie/jemalloc (I understand this suggestion should be filed as a separate report on the jemalloc launchpad). Currently jemalloc 3.5.1 is in the trusty repos; 3.6.0 claims to provide an important fix for a crasher and should probably be brought down, but doesn't appear to introduce any modifications that would affect redis's functionality.

"make test" runs without issue. All tests pass. I am running the binaries built from this package without issue now.

This upgrade is badly needed. CVE-2015-4335 is being actively exploited in the wild. Please let me know what else is needed to proceed.

[Jeff Cook (jeff.cook.wildworks)]

(no longer expired per #3)

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "debdiff redis 2.8.4-2 -> 2.8.24-1" 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.]

[Mattia Rizzolo (mapreri)]

So, this bug affects only trusty.
The point is, during SRU you can't upgrade a package like redis to a whole new upstream release, but rather you should cherry-pick the relevant patch (like https://github.com/lamby/pkg-redis/commit/c2b56ef2d39bd681b3f98cd97354790ac19a1ce5).

See:
http://wiki.ubuntu.com/SRU
https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures

[Jeff Cook (jeff.cook.wildworks)]

As a long-time user of both Ubuntu and Debian, I understand that typically, new major upstream versions do not get inserted into stable releases. My personal experience is that microversion bumps are frequently brought into the stable releases, and section 2.3 of the linked page seems to describe the process for that in detail. I believe redis meets at least 3 of the 4 criteria listed on that page (I don't know if the package has an "autopkgtest" component).

The worst incompatibility is the PUBSUB response was changed from a string to an integer in 2.8.13. I would hope that isn't an excuse to keep trusty on an ancient version; if it presents a problem for upgrading, it would seem best to *revert* that individual patch for API consistency rather than keeping the whole package back on a release with numerous major problems, including active security problems.

Per the page linked, I understand that the stable release team has the final input into whether a package gets microversion bumps (such as this one, 2.8.4 -> 2.8.24). I just want to clarify that I'm aware of the release process and that I believe in this case, the microversion bump is not only justified but needed.

[Mattia Rizzolo (mapreri)]

Right. I'm not convinced that it's _needed_ but it can be done indeed. Though, I'm not personally up to sponsor it.
Besides, I'd rather see this bug only about the CVE; if anybody wants to provide a minimal patch for it, and follow the SRU procedure (which includes testing once it reaches proposed), it's a lot easier to find sponsorship.

[Marc Deslauriers (mdeslaur)]

Thanks for the debdiff! Unfortunately, as mentioned earlier, going from 2.8.4 to 2.8.24 is too intrusive to be sponsored by the security team. There is no way for us to adequately test how such a big version bump will affect other packages in the archive that depend on redis, or adequately test how it would affect how redis is being used in production by users.

If you are interested in getting a security update sponsored for CVE-2015-4335, I suggest simply backporting the following commit:

https://github.com/antirez/redis/commit/fdf9d455098f54f7666c702ae464e6ea21e25411

Much like Debian has done:

https://github.com/lamby/pkg-redis/commit/c2b56ef2d39bd681b3f98cd97354790ac19a1ce5

I am unsubscribing ubuntu-security-sponsors for now. Please re-subscribe the group once a new debdiff has been submitted.