Hi all,

15th of March 2019 I sent a communication, alongside with patches to fix two vulnerabilities in Redis.

  1. The HyperLogLog code implementation had insufficient sanity checks, resulting in a buffer overflow. This was reported by @JohnSully.
  2. Moreover @JohnSully reported a DoS: Redis could be crashed in case it was possible to call REPLICAOF in the wrong context. This is less a problem because normally cloud providers do not expose the REPLICAOF command.

A few hours later:

  1. Auditing the same code paths I found two more issues in hyperloglog.c, that were also fixed.

I provided the fixes to a number of companies running Redis as a service, in order for them to get the vulnerabilities fixed. Who runs Redis in their own systems is a lot less affected by this issues, if you have trusted clients, they can anyway do a lot of damage (this will change in Redis 6 because of ACLs). So what happened was the following:

  1. 15th of March: I reported the vulnerabilities to a closed list of cloud providers, the Debian Linux distribution maintainers, and other folks that previously helped with Redis security.
  2. 15th of March (later in the day): I did some auditing and found other issues in the hyperloglog file. I updated the patches.
  3. 18th of March: I released Redis 5.0.4, 4.0.14 and 3.2.13, with silent fixes. Actually there was nothing misleading in the commit messages, just security implications were not mentioned.
  4. We gave time to upgrade.
  5. Now 8 July 2019 I'm releasing such statement.

The commits fixing all these issues are the following:

For the HyperLogLog:

  • e216ceaf HyperLogLog: handle wrong offset in the base case.
  • a4b90be9 HyperLogLog: enlarge reghisto variable for safety.
  • 9f13b2bd Fix hyperloglog corruption

The other vulnerability was a DoS that was fixed here: * 5b52bc73 Replicas aren't allowed to run the replicaof command

Hopefully you may already running a fixed Redis because we upgraded all the versions 18th of March, otherwise you may think about upgrading in case your clients are not trusted or for any other reason regarding your security policy.

Comment From: lamby

FYI https://security-tracker.debian.org/tracker/CVE-2019-10192 and https://security-tracker.debian.org/tracker/CVE-2019-10193 relate to this issue.

Comment From: carnil

So the mapping for the two CVEs to the commits seem to be:

  • CVE-2019-10192
  • https://github.com/antirez/redis/commit/e216ceaf0e099536fe3658a29dcb725d812364e0
  • https://github.com/antirez/redis/commit/9f13b2bd4967334b1701c6eccdf53760cb13f79e
  • Red Hat reference: https://bugzilla.redhat.com/show_bug.cgi?id=1723918
  • CVE-2019-10193
  • https://github.com/antirez/redis/commit/a4b90be9fcd5e1668ac941cabce3b1ab38dbe326
  • Red Hat reference: https://bugzilla.redhat.com/show_bug.cgi?id=1727668
  • no CVE for the DoS issue.

Debian Bug: https://bugs.debian.org/931625