We could find no evidence of serialised objects passed or exposed to the browser in our in-house testing.
This doesn't exclude the bug being present if vulnerable code is present, since blackbox testing can't easily identify and exercise all possible code paths; also we didn't examine server to server communication in depth, although only one set of comms to Jive was identified as using HTTP (as opposed to HTTPS, although the server used supports HTTPS), and we reported that to Jive, but no serialised objects were seen in the packet dump.
There are a considerable number of Java components with known issues in the Jive 8.0.2 release I examined, of which the Java serialisation object code is but one. Including some components from Apache which are in their sunset period, and distinctly unloved.
We have previously supplied Jive with the output of OWASP dependency checker for these types of issue, and will happily do so again, although the tool is free to download and run, and not without its own faults.
Let me raise this internally. The last version of the code base I saw had version 3.2.1, but that was a while ago. Stay tuned.
2 people found this helpful
From our security team:
After internal investigation and testing, we found no evidence of the Jive application itself being vulnerable to the recently announced remote code execution vulnerabilities in Apache Commons. In addition, Jive instances hosted in our datacenter are at less risk of most known exploits of this vulnerability, as our network controls prevent access to affected ports, such as those used by Tomcat for administration and debugging purposes. The customer instances are completely VLAN isolated from other customer instances, and the Jive network is fronted from the Internet by a load balancer which only allows ingress traffic on ports 80 and 443.
Hope that helps answer your question.