Bug 2004547 (CVE-2022-3433)

Summary:	CVE-2022-3433 ghc-aeson: untrusted JSON input leads to hash collisions and DoS
Product:	[Other] Security Response	Reporter:	Marian Rehak <mrehak>
Component:	vulnerability	Assignee:	Nobody <nobody>
Status:	NEW ---	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	ftweedal, gsuckevi, petersen
Target Milestone:	---	Keywords:	Reopened, Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	aeson 2.0.1.0	Doc Type:	If docs needed, set a value
Doc Text:	The aeson library is not safe to use to consume untrusted JSON input. A remote user could abuse this flaw to produce a hash collision in the underlying unordered-containers library by sending specially crafted JSON data, resulting in a denial of service.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-10-05 12:21:17 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	2004548, 2004549, 2133096
Bug Blocks:	2004550

Description Marian Rehak 2021-09-15 14:30:47 UTC

The aeson library is not safe to use to consume untrusted input, like the JSON values that a web server might parse, this allows DoS.

External Reference:

https://cs-syd.eu/posts/2021-09-11-json-vulnerability

Comment 1 Marian Rehak 2021-09-15 14:31:05 UTC

Created ghc-aeson tracking bugs for this issue:

Affects: epel-7 [bug 2004549]
Affects: fedora-all [bug 2004548]

Comment 3 Guilherme de Almeida Suckevicz 2022-09-27 17:40:51 UTC

*** Bug 2130280 has been marked as a duplicate of this bug. ***

Comment 5 Fraser Tweedale 2022-09-28 09:47:01 UTC

I disagree - strongly - with the assessment that it is not worthy of a CVE assignment.

This issue is not about the unordered-containers library.  This issue is with aeson,
the most widely used JSON library in the Haskell ecosystem.  aeson prior to v2.0 used
HashMap (from unordered-containers) unconditionally, making it vulnerable to hash flooding.
Any service or program that used aeson < 2.0 and handled untrusted input could be
vulnerable to hash flooding, without explicit countermeasures such as
input size limits, rate limits, etc.

Hash flooding / HashDOS vulnerabilities in data libraries are usually assigned CVEs.
Search the database for "hash flood", "hashdos", "hash collision", etc.  Please assign
a CVE for this one too.

Comment 7 Jens Petersen 2022-09-28 12:57:14 UTC

I think CVE-2021-41119 is this issue, right?

Comment 8 Fraser Tweedale 2022-09-29 04:04:53 UTC

Well, yes and no.  That CVE is specifically for wire-server, which was vulnerable because
it uses aeson.

I would expect a CVE / advisory to be filed against the aeson library itself.

Comment 9 Fraser Tweedale 2022-10-05 23:33:10 UTC

Reopening this ticket.  I feel that the decision not to assign a CVE for the hash flood vulnerability
within aeson itself (versions < 2.0) is incorrect.

Comment 10 Mauro Matteo Cascella 2022-10-07 20:31:42 UTC

Thanks for your feedback. This issue was assigned CVE-2022-3433.