Please clarify fixing commits for CVE-2019-10193

[lamby]

Recently, two CVEs were filed for redis:

• https://security-tracker.debian.org/tracker/CVE-2019-10192
• https://security-tracker.debian.org/tracker/CVE-2019-10193

For the first (ie. CVE-2019-10192) it is clear that this was fixed in 9f13b2b and e216cea. However, for the second (ie. CVE-2019-10193), it is not clear what commits will remedy this.

I've done a quick glance at the git blame output for this function with no dice...

Any pointers? :)

[antirez]

Hi @lamby, the CVEs are mostly unreadable. The HyperLogLog issues where fixed in the following commits.

• e216cea HyperLogLog: handle wrong offset in the base case.
• a4b90be HyperLogLog: enlarge reghisto variable for safety.
• 9f13b2b Fix hyperloglog corruption

The other vulnerability was a DoS that was fixed here: 5b52bc7

The above CVEs have no description of what is going on at all: just in one there is a link to bugzilla with little more info, so well... not sure what to say.

[antirez]

P.S. I think I'll release a security advisor myself as a Redis issue.

[lamby]

e216cea HyperLogLog: handle wrong offset in the base case.
9f13b2b Fix hyperloglog corruption

Those appear to be part of CVE-2019-10192. Are you saying that:

a4b90be HyperLogLog: enlarge reghisto variable for safety.

… is also part of that, or are you completely in the dark too? ^_^

The other vulnerability was a DoS that was fixed here: 5b52bc7

This doesn't sound like CVE-2019-101923 from its description, so maybe there's another CVE number waiting to be assigned.

Hm. :)

[antirez]

@lamby basically a4b90be is another bug that I found after I got the report for the other hyperloglog bug. It's a similar issue I found doing the auditing. @JohnSully reported an out of range memory access, I found another similar in another place, and also I found another bug again related to hyperloglog and registers access in yet another place. That's the story.

[lamby]

Cheer for sharing. Okay, I'll give it a few days or so for that Bugzilla link to throw up something interesting about CVE-2019-101923 ...

[antirez]

I released a statement here @lamby #6215

[lamby]

Whilst I thank you releasing that advisory statement, I don't think we have resolved the question of CVE-2019-101923 but I grant that is not in your hands. Lets move all discussion to #6215.

[JohnSully]

I found the original issues. Feel free to contact me if you have any questions. john at csquare dot ca.

[lamby]

@JohnSully Can you share here? I'm, in particular, interested in CVE-2019-101923 …

[JohnSully]

I thought Antirez explained it well, but that is probably because I'm too close to the actual code. The short story is Redis was computing addresses relative to the stack pointer that could be directly influenced by user data. As part of a hyperloglog datastructure there are sparse areas, and when Redis tries to convert them to non-sparse it skips over them in the array allocated on the stack. Because it failed to bounds check you could overflow. With some limitations that overflow and the data written was controlled by the attacker.

I'm not a security researcher so I'm not quite used to heavily distilling these bugs. Let me know if you need more/different details. My main interest is I run a fork called KeyDB and was performing security testing on that code.

[lamby]

Thanks. However, whilst I understood how/what the referenced commits are fixing I am trying to — from a closing all loopholes / administrative point of view — working what, exactly, that latter CVE is referring to. If it is closed by one of the commits, that's great... but that is still not clear. :)

[JohnSully]

Ah sorry for the misunderstanding. Since the commits are Antirez's I'll let him answer.