Bug 26623 - json-c new security issue CVE-2020-12762
Summary: json-c new security issue CVE-2020-12762
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 7
Hardware: All Linux
Priority: Normal major
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
Whiteboard: MGA7-64-OK
Keywords: advisory, has_procedure, validated_update
Depends on:
Reported: 2020-05-14 22:31 CEST by David Walser
Modified: 2020-05-29 23:20 CEST (History)
6 users (show)

See Also:
Source RPM: json-c-0.13.1-3.mga8.src.rpm
Status comment:


Description David Walser 2020-05-14 22:31:16 CEST
Ubuntu has issued an advisory today (May 14):

Mageia 7 is also affected.
David Walser 2020-05-14 22:31:22 CEST

Whiteboard: (none) => MGA7TOO

Comment 1 Lewis Smith 2020-05-15 09:18:44 CEST
Assigning this globally because of no specific maintainer.

Assignee: bugsquad => pkg-bugs

Comment 2 David Walser 2020-05-18 17:21:47 CEST
Fixed in Cauldron in json-c-0.13.1-4.mga8 by Mike.

CC: (none) => mrambo
Whiteboard: MGA7TOO => (none)
Version: Cauldron => 7

Comment 3 Mike Rambo 2020-05-18 17:52:02 CEST
Patched package uploaded for cauldron and Mageia 7.


Updated json-c package fixes security vulnerabilities:

It was discovered that json-c through 0.14 has an integer overflow and out-of-bounds write via a large JSON file, as demonstrated by printbuf_memappend (CVE-2020-12762).


Updated packages in core/updates_testing:

from json-c-0.13.1-2.1.mga7.src.rpm

Testing hints https://bugs.mageia.org/show_bug.cgi?id=13179#c12

Assignee: pkg-bugs => qa-bugs
Keywords: (none) => has_procedure

Comment 4 Herman Viaene 2020-05-19 15:23:49 CEST
MGA7-64 Plasma on Lenovo B50
No installation issues.
Downloaded encode and decode functions from json website and run one from CLI:
$ php function.json-encode.php 
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en">

  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">

  <title>PHP: json_encode - Manual </title>
and that goes on for a few hundred (I guess) lines. But this is really not my terrain, I don't know what to male of it.

CC: (none) => herman.viaene

Comment 5 Len Lawrence 2020-05-19 18:59:38 CEST
Thanks, Herman.  I have been working on this for the last hour or so.

mga7, x86_64

Updated the  two packages.

While 'urpmq --whatrequires-recursive lib64json-c4' does return php-cli, running the example scripts from https://www.php.net/manual/en/function.json-decode.php under strace does not indicate any calls to the library.  /usr/lib64/php/extensions/json.so is mentioned.

$ urpmq --requires-recursive php-json
does return lib64json-c4.

On this basis I shall follow the procedure outlined in bug https://bugs.mageia.org/show_bug.cgi?id=13179#c12 using php-cli.

json_decode examples:
$ php example1.php
object(stdClass)#1 (5) {
$ php example2.php
$ php example3.php

<no output because the code contains deliberate errors>
$ php example4.php
array(1) {
  array(2) {
    array(2) {
      string(3) "One"
      string(7) "January"
    array(2) {
      string(3) "Une"
      string(7) "Janvier"


$ php example5.php

object(stdClass)#1 (1) {
object(stdClass)#1 (1) {
  string(20) "12345678901234567890"

These results mirror those reported on the web.

The outputs from the five json_encode examples also match the outputs on the PHP documentation site.

There are three json_last_error code snippets which also run as expected, more or less.
$ php example1.php

Decoding: {"Organization": "PHP Documentation Team"} - No errors
Decoding: {'Organization': 'PHP Documentation Team'} - Syntax error, malformed JSON

$ php example2.php

<This differs from the published result - the first line should have been
string(4) "null"
Running this in a browser at port 8000 also returns "bool(false) bool(true)">
$ php example3.php


So in general, judging by these examples, the library works but I am reluctant to pass it on until somebody can confirm that the slight divergence reported here is trivial or not.  Could it be a documentation error for instance?

CC: (none) => tarazed25

Comment 6 David Walser 2020-05-20 23:55:46 CEST
We should update this again.  There was a regression in Ubuntu's initial patch:

Keywords: (none) => feedback

Comment 7 David Walser 2020-05-21 00:16:46 CEST
Fedora has issued an advisory for this on May 17:
Comment 8 Len Lawrence 2020-05-24 19:43:14 CEST

$ cat exploit.c
#include <json-c/json_util.h>
#include <unistd.h>
int main() {
  json_object_from_fd( STDIN_FILENO );
  return 0;

$ gcc -o exploit $(pkg-config --libs json-c) exploit.c

$ dd if=/dev/zero of=poc.json bs=1 count=1 seek=2147483647
1+0 records in
1+0 records out
1 byte copied, 0.00018232 s, 5.5 kB/s
$ ll poc.json
-rw-r--r-- 1 lcl lcl 2147483648 May 24 18:11 poc.json

Run the PoC:
$ (dd if=poc.json bs=4096; sleep 1; dd if=test.json bs=10) 2>/dev/null | ./exploit
That fails of course on test.json which does not exist.  It is not clear exactly what this is doing apart from creating a JSON file from a huge stream of zeroes.  However, this attempt to test the exploit is using the updated package.  And are we waiting for another update?  Confused again.
Comment 9 Len Lawrence 2020-05-24 19:50:53 CEST
s/creating a JSON file/creating a JSON object/
Comment 10 Len Lawrence 2020-05-24 19:57:36 CEST
Ah.  The exploit is trying to tack on a some more bytes at the end of the object and so trigger the issue.  Need to find a JSON file.
Comment 11 Len Lawrence 2020-05-24 22:11:05 CEST
Right.  Moved to another machine with the pre-update version of json-c.
Recompiled exploit.
Running the exploit program eventually caused a crash.
$ (dd if=poc.json bs=4096; sleep 1; dd if=test.json bs=10) 2>/dev/null | ./exploit
Segmentation fault (core dumped)
Updated the two packages, recompiled and  ran the test again.  Clean exit after 1 second.
So the current update fixes this particular issue.
Comment 12 Mike Rambo 2020-05-25 19:08:02 CEST
Added upstream patch to fix regression in previous update. Patched packages uploaded for both Cauldron and Mageia 7.

Updated files list for Mageia 7.


from json-c-0.13.1-2.2.mga7.src.rpm

Keywords: feedback => (none)

Comment 13 Len Lawrence 2020-05-26 19:48:45 CEST
Updated again and ran the simple php examples tested before including
the encode examples, at the site linked to in comment 5.
The decode and last_error examples returned exactly the same results as before.

$ php example1.php

$ php example2.php
Normal: ["<foo>","'bar'","\"baz\"","&blong&","\u00e9"]
Tags: ["\u003Cfoo\u003E","'bar'","\"baz\"","&blong&","\u00e9"]
Apos: ["<foo>","\u0027bar\u0027","\"baz\"","&blong&","\u00e9"]
Quot: ["<foo>","'bar'","\u0022baz\u0022","&blong&","\u00e9"]
Amp: ["<foo>","'bar'","\"baz\"","\u0026blong\u0026","\u00e9"]
Unicode: ["<foo>","'bar'","\"baz\"","&blong&","é"]
All: ["\u003Cfoo\u003E","\u0027bar\u0027","\u0022baz\u0022","\u0026blong\u0026","é"]

Empty array output as array: []
Empty array output as object: {}

Non-associative array output as array: [[1,2,3]]
Non-associative array output as object: {"0":{"0":1,"1":2,"2":3}}

Associative array always output as object: {"foo":"bar","baz":"long"}
Associative array always output as object: {"foo":"bar","baz":"long"}

$ php example3.php
Strings representing numbers automatically turned into numbers
array(4) {
  string(7) "+123123"
  string(7) "-123123"
  string(5) "1.2e3"
  string(7) "0.00001"
string(28) "[123123,-123123,1200,1.0e-5]"
Strings containing improperly formatted numbers
array(2) {
  string(13) "+a33123456789"
  string(4) "a123"
string(24) "["+a33123456789","a123"]"

$ php example4.php
Sequential array
array(4) {
  string(3) "foo"
  string(3) "bar"
  string(3) "baz"
  string(5) "blong"
string(27) "["foo","bar","baz","blong"]"

Non-sequential array
array(4) {
  string(3) "foo"
  string(3) "bar"
  string(3) "baz"
  string(5) "blong"
string(43) "{"1":"foo","2":"bar","3":"baz","4":"blong"}"

Sequential array with one key unset
array(3) {
  string(3) "foo"
  string(3) "baz"
  string(5) "blong"
string(33) "{"0":"foo","2":"baz","3":"blong"}"

$ php example5.php
string(4) "12.0"
string(2) "12"

These results also match those online.

Giving this the green light again.

Whiteboard: (none) => MGA7-64-OK

Comment 14 Thomas Andrews 2020-05-28 15:26:21 CEST
Thank you for your effort, Len. Validating. Advisory information in Comments 3, 7, and 12.

Keywords: (none) => validated_update
CC: (none) => andrewsfarm, sysadmin-bugs

Comment 15 David Walser 2020-05-28 18:15:55 CEST
Do we still have the correct fix?  Ubuntu issued another regression fix update:
Comment 16 Len Lawrence 2020-05-28 20:56:06 CEST
Is it this issue?
cannot add more than 11 objects.
Issue exists in 0.14 but NOT in 0.13.1

I shall run the PoC if it is relevant.
Comment 17 Len Lawrence 2020-05-28 21:05:41 CEST
I ran it for 0.13.1 and it generated 99 objects.
Comment 18 Mike Rambo 2020-05-28 21:46:03 CEST
(In reply to David Walser from comment #15)
> Do we still have the correct fix?  Ubuntu issued another regression fix
> update:
> https://usn.ubuntu.com/4360-4/

Looks to me like we do. It looks like all they did was to redo the original patch to incorporate the regression patch change instead of carrying the regression fix as a separate patch. They did also add back the test suite change which they left off their original patch series. So, excepting the test suite code, our package has everything theirs has. It's just that ours has the regression fix as a separate patch.
Comment 19 David Walser 2020-05-28 21:58:06 CEST
Ok, I thought that might be the case but wanted to make sure.  Thanks Mike!
Nicolas Lécureuil 2020-05-28 22:53:11 CEST

Keywords: (none) => advisory
CC: (none) => mageia

Comment 20 Mageia Robot 2020-05-29 23:20:07 CEST
An update for this issue has been pushed to the Mageia Updates repository.


Resolution: (none) => FIXED

Note You need to log in before you can comment on or make changes to this bug.