json-c-0.11: Fix CVE-2020-12762 - json-c through 0.14 has an integer overflow and out-of-bounds write ...

[besser82]

This PR is a squashed and slightly modified backport of the following commits on the master branch:

• 77d935b
• d07b910
• 519dfe1
• a59d5ac

[besser82]

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12762

[besser82]

CI failure is unrelated. Build finishes fine locally.

[hawicz]

Is anyone still using this ancient of a version of json-c? The most recent change on the v0.11 branch was more than 7 years ago. If there's a real world example of someone actually using this version and being unable to upgrade to a newer release, then we could merge this. Otherwise I'm inclined to declare this branch out-of-support and not make any changes here so as to avoid giving the impression that it's actually an active branch.

[besser82]

Is anyone still using this ancient of a version of json-c? The most recent change on the v0.11 branch was more than 7 years ago. If there's a real world example of someone actually using this version and being unable to upgrade to a newer release, then we could merge this.

Well, Debian Jessie (9.x, oldoldstable), Ubuntu 16.04.6 LTS (Xenial Xerus), and Red Hat Enterprise Linux / CentOS {6,7} are shipping json-c-0.11. I doubt it will be an easy task to update them to json-c-0.12.x, as it is not fully binary compatible, and thus would require to rebuild several components of those distributions.

[hawicz]

Based on a comparison I just did w/ abi-compliance-checker, the one significant change that I see is the removal of the json_tokener_errors[] symbol. I'd be far more inclined to merge a change to 0.12 to drop the "static" from its declaration in json_tokener.c on that branch, and thus restore at ABI compatibility, than to merge this change.

[besser82]

From the technical POV I get your point, but there is at least another aspect to consider when updating from v0.11 to v0.12 instead of patching v0.11 to fix the CVE: What about existing certifications and/or security audits those distributions and/or products have undergone to be suitable for special audiances?

For FIPS-180 certification I know there is a huge difference between adding a patch and updating to a different version:

• For patching it is sufficient when the isolated patch will be reviewed and/or audited.
• Updating the version implies a review or an audit for the complete chain of applications that link against that component.

This consideration at least applies to RHEL {6,7}.

[hawicz]

Apologies for forgetting about this. I still have reservations about making it seem like the old branches are actually active, but since those OS version that use it are still in support for at least a few more years I've merged this PR anyway.