An issue was discovered in netplex json-smart-v1 through 2015-10-23 and json-smart-v2 through 2.4. An exception is thrown from a function, but it is not caught, as demonstrated by NumberFormatException. When it is not caught, it may cause programs using the library to crash or expose sensitive information. Upstream Reference: https://github.com/netplex/json-smart-v1/issues/7 https://github.com/netplex/json-smart-v2/issues/60
A word on scoring, our scoring is currently 9.1/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H and NVD of 9.1/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H will change to 5.9/CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H My take: Exploitability Metrics: Attack Vector Network (AV:N) Mostly agree here, although the json-smart application library itself is not bound to the network stack it is commonly used in end applications bound to the network stack to parse json data. ie. The JSON data can originate from a WAN Attack Complexity Low (AC:L) -> Attack Complexity High (AC:H): We disagree with the original scoring of a low attack complexity, we believe the impact is significantly different depending on the specific end applications handling, that is to say a successful attack depends on conditions beyond the attacker's control, we believe those conditions are - *) The attacker must have an injection point to introduce malicious or badly formatted JSON data, this is dependent on the end application design and is an element outside the attackers control *) The end application has no handling of general exceptions (in this case NumberFormatException), again this is dependent on the end application design and end application termination may be a desired outcome in some circumstances. *) In order to have a high impact upon confidentiality the stack trace containing the sensitive information would need to be returned to the attacker, again this is end application implementation dependent but stack trace information which may contain the sensitive information from a RuntimeException will not commonly be reflected to a remote attacker, this in conjunction with the need for the attacker to inject the malicious JSON data in the first place Privileges Required None (PR:N) Agree here, the attacker does not need to be a privileged user eg. no login required to exploit the base flaw. User Interaction None (UI:N) Mostly agree here, a user does not need to be coerced into performing any action for this flaw, an attacker can expect to be successful if the user is simply using the service at the same time, so the attack cannot except such a high impact without another user but the attack is still possible regardless. Scope Unchanged (S:U) Agree here, the attacker will not be able to escape the scope of the executing JVM solely due to this flaw Impact Metrics: Confidentiality High (C:H) -> Confidentiality None (C:N) We disagree with the original scoring of high impact upon confidentiality, we can see no evidence of confidential information being disclosed or reflected via the stacktrace generated from the exception, adding to this, any information in the stack trace (ie. the bad json value) has to of been mutable by the attacker in order to exploit the flaw Integrity High (I:N) Agree here, there is no loss of integrity within the impacted component or end application upon a success attack, the attacker is unable to modify any data. Availability High (A:H) Agree here, this flaw has the potential to cause a total loss of availability in end applications if the exception generated is unhandled
This issue has been addressed in the following products: Red Hat AMQ Streams 1.8.0 Via RHSA-2021:3225 https://access.redhat.com/errata/RHSA-2021:3225
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2021-27568
This issue has been addressed in the following products: Red Hat Integration Via RHSA-2021:4767 https://access.redhat.com/errata/RHSA-2021:4767
This issue has been addressed in the following products: Red Hat Integration Via RHSA-2021:4918 https://access.redhat.com/errata/RHSA-2021:4918
This issue has been addressed in the following products: Red Hat Fuse 7.10 Via RHSA-2021:5134 https://access.redhat.com/errata/RHSA-2021:5134