Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#38958 - [jansson] security patch for CVE-2013-6401
Attached to Project:
Community Packages
Opened by RbN (RbN) - Tuesday, 18 February 2014, 20:43 GMT
Last edited by Kyle Keen (keenerd) - Wednesday, 16 April 2014, 05:20 GMT
Opened by RbN (RbN) - Tuesday, 18 February 2014, 20:43 GMT
Last edited by Kyle Keen (keenerd) - Wednesday, 16 April 2014, 05:20 GMT
|
DetailsDescription:
Florian Weimer of the Red Hat Product Security Team found that the hashing implementation in Jansson, a library for encoding, decoding and manipulating JSON data, was susceptible to predictable hash collisions. A remote attacker could use this flaw to cause an application using Jansson to use an excessive amount of CPU time by sending a crafted JSON document containing a large number of parameters whose names map to the same hash value. (CVE-2013-6401) Redhat Bug [0] Resolution: apply patchs [1] and [2] Ressources: [0] https://bugzilla.redhat.com/show_bug.cgi?id=1035538 [1] https://github.com/akheron/jansson/commit/42016a35c8907e477be73b0b5d06cc09af231ee4 [2] https://github.com/akheron/jansson/commit/8f80c2d83808150724d31793e6ade92749b1faa4 |
This task depends upon
Closed by Kyle Keen (keenerd)
Wednesday, 16 April 2014, 05:20 GMT
Reason for closing: Fixed
Additional comments about closing: Fixed in jansson-2.6-1
Wednesday, 16 April 2014, 05:20 GMT
Reason for closing: Fixed
Additional comments about closing: Fixed in jansson-2.6-1
Comment by Daniel Micay (thestinger) -
Thursday, 20 February 2014, 03:40 GMT
It's still vulnerable to hash collisions. The chosen hash is vulnerable to key independent collision attacks. This would need to be switched to SipHash to be truly secure from these kind of attacks. I don't see a point in this half-measure.