Bug 13179 - json-c new security issues CVE-2013-6370 and CVE-2013-6371
: json-c new security issues CVE-2013-6370 and CVE-2013-6371
Status: RESOLVED FIXED
Product: Mageia
Classification: Unclassified
Component: Security
: 4
: i586 Linux
: Normal Severity: major
: ---
Assigned To: QA Team
: Sec team
: http://lwn.net/Vulnerabilities/595049/
: MGA3TOO has_procedure advisory MGA4-6...
: validated_update
:
:
  Show dependency treegraph
 
Reported: 2014-04-09 17:43 CEST by David Walser
Modified: 2014-04-17 13:50 CEST (History)
5 users (show)

See Also:
Source RPM: json-c-0.11-3.mga4.src.rpm
CVE:
Status comment:


Attachments

Description David Walser 2014-04-09 17:43:15 CEST
Two security issues in json-c were announced today (April 9):
http://openwall.com/lists/oss-security/2014/04/09/9

The upstream commit to fix them is linked, but it doesn't quite apply as-is to 0.11.

Mageia 3 and Mageia 4 are also affected.

Reproducible: 

Steps to Reproduce:
Comment 1 Oden Eriksson 2014-04-09 18:04:39 CEST
It does if you hack a little, like:

mv configure.in configure.ac
patch ...
mv configure.ac configure.in

and, make a new patch.
Comment 2 David Walser 2014-04-09 20:25:50 CEST
(In reply to Oden Eriksson from comment #1)
> It does if you hack a little, like:
> 
> mv configure.in configure.ac
> patch ...
> mv configure.ac configure.in
> 
> and, make a new patch.

OK, that works fine for Mageia 4 and Cauldron.  Should we just update Mageia 3 to the same tarball?
Comment 3 David Walser 2014-04-09 20:26:48 CEST
Checked into SVN for Mageia 4 and Cauldron.
Comment 4 Colin Guthrie 2014-04-09 20:33:13 CEST
I would probably vote for updating mga3 version provided PulseAudio and PHP (if it uses it in MGA3) are both OK with it (it has been a bit ABI unstable in the past with updates, but I think that was in the MGA2 days)
Comment 5 David Walser 2014-04-09 20:39:19 CEST
The only things using it in Mageia 3 are abrt/libreport and pulseaudio.  The major number of the json library is still 2, not that that guarantees everything.  I know ROSA has a tool to check for ABI changes in newer versions of libraries; it'd be nice to have something like that.
Comment 6 David Walser 2014-04-10 00:30:55 CEST
Oden, the affected code is in the jsonc tarball in the PHP SRPM, does that need to be patched too?  I do see that php-json in mga4/Cauldron is linked to the system libjson2, so maybe not (in which case I'm not sure why we bundle that code).
Comment 7 Oden Eriksson 2014-04-10 08:27:27 CEST
The json php extension bundled with php was replaced with http://pecl.php.net/package/jsonc due to a license violation:

http://www.json.org/license.html

"The Software shall be used for Good, not Evil."

This was not done for mga3, but could be done easily.

You could push the final json-c (https://s3.amazonaws.com/json-c_releases/releases/json-c-0.11.tar.gz) as in mga4 to mga3 and request QA to test the affected softwares.
Comment 8 David Walser 2014-04-10 16:20:10 CEST
OK, Mageia 3 json-c tarball is updated.

Patched package uploaded for Mageia 3, Mageia 4, and Cauldron.

Note to QA: pulseaudio is the most important consumer of this library, and the pulseaudio library uses it for parsing JSON (for what exactly, I'm not sure).  I'd imagine if pulseaudio runs fine after rebooting, it should be fine.  In Mageia 4, php-json also uses this library, so a simple test case may be able to be constructed using that.

Advisory:
========================

Updated json-c packages fix security vulnerabilities:

Florian Weimer reported that the printbuf APIs used in the json-c library used
ints for counting buffer lengths, which is inappropriate for 32bit
architectures.  These functions need to be changed to using size_t if possible
for sizes, or to be hardened against negative values if not.  This could be
used to cause a denial of service in an application linked to the json-c
library (CVE-2013-6370).

Florian Weimer reported that the hash function in the json-c library was weak,
and that parsing smallish JSON strings showed quadratic timing behaviour.
This could cause an application linked to the json-c library, and that
processes some specially-crafted JSON data, to use excessive amounts of CPU
(CVE-2013-6371).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6370
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6371
https://bugzilla.redhat.com/show_bug.cgi?id=1032322
https://bugzilla.redhat.com/show_bug.cgi?id=1032311
========================

Updated packages in core/updates_testing:
========================
libjson2-0.11-1.mga3
libjson-devel-0.11-1.mga3
libjson2-0.11-3.1.mga4
libjson-devel-0.11-3.1.mga4

from SRPMS:
json-c-0.11-1.mga3.src.rpm
json-c-0.11-3.1.mga4.src.rpm
Comment 9 Lewis Smith 2014-04-10 20:39:43 CEST
While I have the information handy, this URL leads to specific PHP code examples, with their output, for json_decode, json_encode which should help testing with PHP - which you do not even need to know, it is given:-
 http://www.php.net/manual/en/ref.json.php
Comment 10 claire robinson 2014-04-14 17:54:10 CEST
It appears php-json only requires (recursively) libjson2 in mga4. Is this a packaging error in mga3 or does mga3 php-json contain a static libjson2? If so it might need to be rebuilt too.

mga4..
$ urpmq --whatrequires lib64json2
abrt-plugin-bodhi
grive
lib64json-devel
lib64json2
lib64pulseaudio0
lib64report-web0
libreport-plugin-ureport
mypaint
php-json
php-json
postgis

$ urpmq --requires-recursive php-json
bash
bash-completion
dash-static
filesystem
glibc
lib64ffi6
lib64glib2.0_0
lib64json2
lib64lzma5
lib64ncurses5
lib64pcre1
lib64php5_common5
lib64xml2_2
lib64zlib1|lib64uClibc-zlib1
libgcc1
libstdc++6
ncurses
php-json
pkgconfig
python|python3
run-parts
setup

mga3..
$ urpmq --whatrequires libjson2
abrt-plugin-bodhi
libjson-devel
libjson2
libpulseaudio0
libreport-plugin-ureport
libreport-web0

$ urpmq --requires-recursive php-json
bash
dash-static
filesystem
glibc
libgcc1
liblzma5
libpcre1
libphp5_common5
libstdc++6
libtermcap2
libuClibc-zlib1|libzlib1
libxml2_2
php-json
run-parts
setup
Comment 11 David Walser 2014-04-14 18:00:22 CEST
php-json in Mageia 3 does use bundled code, but it's completely different code, it doesn't contain the code affected by this vulnerability.
Comment 12 Lewis Smith 2014-04-15 21:35:04 CEST
Testing MGA4 real h/w 64-bit

Using Release lib64json2-0.11-3.mga4, ran all the tests indicated from Comment 9 in an HTML page.
They produced the specified results except for no newlines in HTML output, which makes their interpretation difficult. More seriously, "Example #5 json_decode() of large integers" gave a *different* result:-
object(stdClass)#2 (1) { ["number"]=> int(9223372036854775807) } object(stdClass)#2 (1) { ["number"]=> int(9223372036854775807) }
rather than:-
object(stdClass)#1 (1) {
  ["number"]=>
  float(1.2345678901235E+19)
}
object(stdClass)#1 (1) {
  ["number"]=>
  string(20) "12345678901234567890"
}

Updated to lib64json2-0.11-3.1.mga4 from Core Release Testing, re-ran the tests.
All results were the same, including the doubtful "Example #5 json_decode() of large integers".
If this can be explained, this update is good for MGA4-64-OK. Need more expert advice.
Comment 13 David Walser 2014-04-15 22:05:36 CEST
Newlines in HTML code don't produce newlines in the web page.  You'd get more readable output by just running the php file directly with php-cli.
Comment 14 Shlomi Fish 2014-04-16 13:42:24 CEST
Tested a Mageia 4 x86-64 VM. Looks fine before and after the upgrade.
Comment 15 Shlomi Fish 2014-04-16 14:00:17 CEST
Tested on a Mageia 4 i586 VM. Looks fine.
Comment 16 Shlomi Fish 2014-04-16 14:08:26 CEST
MGA3-64-OK.
Comment 17 Shlomi Fish 2014-04-16 14:14:11 CEST
And it's fine on MGA3-32-OK as well.
Comment 18 claire robinson 2014-04-16 14:36:07 CEST
Thanks guys. 

Advisory uploaded. Validating.

Could sysadmin please push to 3 & 4 updates

Thanks
Comment 19 Colin Guthrie 2014-04-16 15:03:25 CEST
Processing now...
Comment 20 Colin Guthrie 2014-04-16 15:17:51 CEST
Update Pushed: http://advisories.mageia.org/MGASA-2014-0175.html

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