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:
Whiteboard: (none) => MGA4TOO, MGA3TOO
It does if you hack a little, like: mv configure.in configure.ac patch ... mv configure.ac configure.in and, make a new patch.
CC: (none) => oe
(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?
Checked into SVN for Mageia 4 and Cauldron.
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)
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.
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).
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.
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
CC: (none) => mageiaVersion: Cauldron => 4Assignee: mageia => qa-bugsWhiteboard: MGA4TOO, MGA3TOO => MGA3TOO
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
CC: (none) => lewyssmith
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
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.
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.
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.
Tested a Mageia 4 x86-64 VM. Looks fine before and after the upgrade.
CC: (none) => shlomifWhiteboard: MGA3TOO => MGA3TOO MGA4-64-OK
Tested on a Mageia 4 i586 VM. Looks fine.
Whiteboard: MGA3TOO MGA4-64-OK => MGA3TOO MGA4-64-OK MGA4-32-OK has_procedure
MGA3-64-OK.
Whiteboard: MGA3TOO MGA4-64-OK MGA4-32-OK has_procedure => MGA3TOO MGA4-64-OK MGA4-32-OK MGA3-64-OK has_procedure
And it's fine on MGA3-32-OK as well.
Whiteboard: MGA3TOO MGA4-64-OK MGA4-32-OK MGA3-64-OK has_procedure => MGA3TOO MGA4-64-OK MGA4-32-OK MGA3-64-OK MGA3-32-OK has_procedure
Thanks guys. Advisory uploaded. Validating. Could sysadmin please push to 3 & 4 updates Thanks
Keywords: (none) => validated_updateWhiteboard: MGA3TOO MGA4-64-OK MGA4-32-OK MGA3-64-OK MGA3-32-OK has_procedure => MGA3TOO has_procedure advisory MGA4-64-OK MGA4-32-OK MGA3-64-OK MGA3-32-OKCC: (none) => sysadmin-bugs
Processing now...
Update Pushed: http://advisories.mageia.org/MGASA-2014-0175.html
Status: NEW => RESOLVEDResolution: (none) => FIXED
URL: (none) => http://lwn.net/Vulnerabilities/595049/