Drop YAJL dependency

[mikelolasagasti]

yajl library has been unmaintained upstream[1] since 2015. Last published release contians multiple CVEs (CVE-2023-33460, CVE-2022-24795, CVE-2017-16516) and fixes have had to be carried by downstream distributions and third parties. This is not an ideal situation. While a fork exists[2], it is unclear how widely adopted or blessed it is downstream.

As the maintainer of libmodsecurity for Fedora[3] and EPEL, I recently found that the yajl library will not be shipped with RHEL 10. This means a new maintainer would be required to add it to EPEL. The previous maintainer for RHEL & EPEL has recommended moving away from yajl[4].

Currently, libmodsecurity can be built without yajl, but I understand that making it mandatory is considered desirable, as per #3144 and #3151.

Given the security concerns and the upstream status of yajl, I recommend opening a discussion on dropping yajl as a dependency and exploring alternative JSON libraries, such as JSON-C, which is actively maintained and more widely adopted.

[1] https://github.com/lloyd/yajl
[2] https://github.com/robohack/yajl/
[3] https://src.fedoraproject.org/rpms/libmodsecurity
[4] https://lists.fedoraproject.org/archives/list/[email protected]/message/YPFHPOKAND3RZR7ZKWTDHUQEESG6IUJ3/

[airween]

Agree, we should change.

What do you think about the "official" YAML library?

[airween]

Note, I added label [2.x] too, because mod_security2 is also affected.

[dune73]

This does not sound good. Thank you for bringing this to the attention @mikelolasagasti.

[berrange]

What do you think about the "official" YAML library?

I'm the Fedora yajl maintainer quoted in the link above. While YAML may be a superset of JSON, I'd not recommend using a YAML parser instead of a native JSON parser. It'll perform worse, and potentially open the code up to attacks that are impossible with pure JSON (aka the "Billion laughs attack" in YAML context). I can vouch for using json-c as an alternative to yajl, as that's what was successfully adopted in projects I work on. Be slightly cautious about jansson - when we previously tried it, we found it was not able to cope with the full numeric range of the uint64 type - if that's important to modsecurity's needs.

[airween]

Hi @berrange,

While YAML may be a superset of JSON, I'd not recommend using a YAML parser instead of a native JSON parser.

You're right, that was a mistake from me - sorry, and thank you.

[dune73]

Thank you for this very valuable input @berrange. That puts the replacement discussion on a far better base.

[marcstern]

These are the libraries that are reported (by their authors and third-parties) as the fastest:

• https://github.com/stephenberry/glaze
• https://github.com/simdjson/simdjson
• https://ibireme.github.io/yyjson/

It would be interesting to check their functionalities for our intended use:

• validation
• callback to store ARGS (or should we avoid that and use only the resulting sJSON onjects?)
• memory footprint

[dune73]

There are a few subtle behavior quirks of yajl that should be examined for alternative libraries too. And then documented in case.

The behavior with empty request body for example. From the back of my head I am no longer sure if yajl rejects that and other parsers are OK with it or if it's the other way around. But I've seen this problem in production before.

[marcstern]

This would definitely need extensive test cases