dependency on cJSON?

[thinrope]

A recent discussion on the Openwall oss-security Mailing List talked about the article "33 Vulnerabilities in cJSON" that got me searching where in my systems is it used... it turned out, for me, only iperf currently seems to need it :-/ ... or at least so I thought.

Given the (claimed) non-maintenance mode of https://github.com/DaveGamble/cJSON I was wondering how deeply dependent is iperf on cjson ...
Digging deeper it is getting weird... I see that there is a local copy of it inside iperf: https://github.com/esnet/iperf/blob/master/src/cjson.c then on my Gentoo systems it is linked to system-wide cjson...

On Gentoo linux, it looks like iperf is coded to require system-wide cjson via a patch:

• the iperf-3.21.ebuild requires the patch
• the iperf-3.18-unbundle-cJSON.patch itself
  In the current situation (until cJSON is fixed upstream) this brings nothing, but at least it shows that the external lib is not that hard to use...

That raises some questions:

• Can iperf be compiled without JSON output (couldn't find any obvious way) ?
• Why was cJSON brought in-tree and what version is it?
• Will it be easy/wise to use out-of-tree (installed in the OS) library?
• Does iperf team need to triage (at least) those 33 vulnerabilities, since I assume they are contained in the distributed cjson, and patch what is needed?

[bmah888]

Hi, thanks very much for the info, we hadn't seen this before. Preliminary answers to your questions:

• No, iperf3 can't be compiled without JSON support. Even if we disabled all JSON output, iperf3 actually uses JSON to pass test parameters and results between the client and the server, so it still needs a JSON library.
• cJSON was included in-tree because we needed some local modifications for 64-bit integers that the upstream maintainer was not willing to accept. (These are necessary for describing or reporting long-running and/or high-speed network tests.) The code in-tree is based on cJSON 1.7.15.
• Because we needed the aformentioned local modifications, it's not going to work perfectly with the OS-installed cJSON. I am actually surprised that Gentoo was able to to make this work (I haven't looked at their build patches).
• To be perfectly frank, the iperf3 team does not have the resources to evaluate all 33 of the vulnerabilities listed in the article. I'd say we would be completely dependent on the upstream cJSON maintainer to fix their problems, assuming we wanted to continue using cJSON.

We haven't decided on a course of action yet.

[davidBar-On]

I briefly scanned the 33 vulnerabilities, and it seems that most of then are not applicable to iperf3. If my (brief...) evaluation is correct, this is because:

• Several issue are for cJSON_Utils.c that is not used by iperf3. (Relevant issues: 1, 2, 3, 9(?), 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24.)
• Several others are for functions in cjson.c that are not used by iperf3. This is assuming the the cJSON functions are not accessible to the iperf3 library users. (Relevant issues: 4, 6, 7, 10, 25, 30, 31, 32.)

Based on the above, then out of the 33 issues only following issues may be relevant to iperf3, depending of iperf3 usage of the cJOSN functions:

• 5 (cJSON_DetachItemViaPointer() - potentially missing a check that parent->child is not NULL).
• 8 (CJSON_CIRCULAR_LIMIT value - depending on iperf3 use, may be NA).
• 26 (accuracy of double float print/compare at the 16/17th digit - may be NA for iperf3).
• 27 (parse_hex4() returns 0 for both 0 hex of illegal hex value).
• 28 (parse_number() returns infinite value for out of range value which is printed as null by print_number()).
• 29 (cJSON_Compare() issue which I am not sure whether it relevant to iperf3 usage.)
• 33 (cJSON_ParseWithOpts() does not clear previous error codes - may not be relevant to iperf3 usage).