CVE-2017-11721: buffer overflow in MSG_ReadBits

[smcv]

@zturtleman recently committed a fix to the Huffman coding in ioquake3's netcode (ioquake/ioq3@d2b1d12). This has been treated as a security vulnerability and CVE-2017-11721 was assigned (by someone, it isn't clear who requested this): see https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11721. As another descendant of the Quake III Arena engine, OpenJK seems to have the same issue.

I believe the situation is:

• When reading data out of a message, a crafted message can arrange for the engine (client or server or both, I'm not sure) to read beyond the message bounds, potentially causing a crash (denial of service) or disclosure of memory contents. Remotely crashing a client or server is a minor security vulnerability (denial of service) so CVE-2017-11721 was assigned.
• When writing data into a message, there is no vulnerability, but the checks for overflow are too pessimistic and can report that a write would overflow when in fact there are a few bytes still available for writing. @zturtleman fixed this too, in the same commit.

(But my interpretation might be wrong, I haven't studied this in detail.)

I have ported the ioquake3 patch to OpenJK's netcode. The result seems to work in some very brief testing, so I have uploaded it to Debian. Please consider merging.

[ensiform]

OpenJK does not have the VoIP system where the issue permeates though, unless it can suddenly be abused elsewhere?

[smcv]

Sorry, I have no idea what this Huffman compression is used for - it might only be VoIP (and hence dead code in OpenJK) or it might be used for normal gameplay.

[ensiform]

Huffman is used for most message transmission, but that does not mean that it was susceptible outside of those parameters. AFAIK the original report was specific to a specially crafted voip packet in ioquake3. If you believe its still vulnerable in general, then maybe its fine.

[smcv]

If the overflow is only exploitable via VoIP in practice, then it doesn't need to be treated as a vulnerability, but I think it would still be worthwhile to fix it (so that OpenJK won't get that vulnerability if it later gains VoIP, or some other feature that uses exploitable Huffman-coding parameters).

This is less of a concern for me than the equivalents in ioquake3 and iortcw, because OpenJK hasn't had any releases yet, and isn't in a Debian release or the branch that will eventually become the next Debian release.

[ensiform]

I would rather this fix instead tbh

ec-/Quake3e@3743137

[Razish]

Reviving this ancient PR; I don't really care which fix gets merged. Let's just merge this PR?
I suspect q3e's has other dependent commits that don't match OJK.
Since it has a CVE against it, I'm gonna merge this if there's no alternative in a week. It's already 6 years overdue.