Developers introduce mitigations, but these are not enabled by default
The FastJSON Java library has been described as “too powerful for its own good” following the discovery of a remote code execution (RCE) vulnerability impacting the software.
The library can be used to convert Java objects into their JSON counterparts using JSONString() and parseObject() methods.
FastJSON accounts for 22,000 stars and 5,900 forks on GitHub. It’s popular, but 1,355 open issues at the time of writing also reveal that security and functionality issues are commonplace.
While useful, deserializing user input and untrusted data comes with its own set of security problems, as demonstrated by researchers Gabriel Lawrence and Chris Frohoff in 2015.
When too much trust is placed in Java serialization, applications and libraries in their entirety can be compromised.
Exploiting deserialization remains a valid attack vector, and as noted by HPE cybersecurity researchers Alvaro Muñoz and Oleksandr Mirosh.
As long as a library uses some form of user-controlled deserialization and there is gadget space in the programming usable to craft logic-abusing payloads, the format used for serialization may not be relevant (PDF) whether in binary, text, or other formats.
FastJSON’s case involves the library’s AutoType feature. AutoType is used to instruct the library to deserialize JSON input using types provided by the JSON and can be used remotely.
As deserialization attacks are well-known, AutoType is not enabled by default – there are class deny lists that prevent risky classes from being instantiated and used in RCE attacks.
A hash function and array are used to maintain the block list. When new classes are found that can cause an RCE, they are added to the deny list with new FastJSON releases.
Stöckli discovered the existence of a global FastJSON instance that can be used to change serialization settings.
If these settings are changed to enable AutoType by one developer and another developer then parses JSON from a remote source using the same codebase and global instance, an RCE is created.
Stöckli also noted that nine AutoType checks are in play, of which such clutter could “enable people to find all kinds of unintended bypasses”. Even if AutoType is not enabled, it may still be possible to instantiate and create some class exceptions in vulnerable versions of the library.
The vulnerability found by Stöckli has been described by Alibaba in a security advisory as the “bypass [of] the AutoType switch to implement deserialization remote code execution and obtain server access permissions”.
FastJSON developers introduced safeMode in version 1.2.68 and this removes support for AutoType, regardless of the deny lists, thereby preventing the RCE from being triggered. However, this mode is not enabled by default.
Speaking to The Daily Swig, Stöckli elaborated on his view that the library is “too powerful for its own good” and suggested that limits should be enabled by default or alternative JSON libraries should be considered, such as Gson.
“It has a safeMode, which is not enabled by default,” Stöckli said. “As a developer, I sleep better if a library is secure by default and [is] only unsafe when requested.”
Furthermore, the developer said that he would not personally choose FastJSON to handle user input.
“FastJSON looks like a gift to the information security world that will keep on giving,” Stöckli commented. “The power of FastJSON might have its ‘raison d’être’ for other purposes like storing complex data objects (which do not directly come from the user).”
Alibaba deemed the issue “important”, fixing the RCE flaw in FastJSON version 1.2.69. FastJSON’s latest release is version 1.2.73, released on July 26.
FastJSON’s safeMode can also be enabled to mitigate the risk of exploit, but Alibaba warns that users should “evaluate the impact on services” before enabling.
The vulnerability may be easy to exploit, but the real-world impact of these kinds of vulnerabilities and the use of exception gadgets is difficult to evaluate.
“I’m currently not aware of any really dangerous commonly used exception gadgets,” Stöckli added. “This depends entirely on the exception classes that are available in a potential target.”