Welcome to the new Gigaspaces XAP forum. To recover your account, please follow these instructions.

Ask Your Question

Is XAP affect by AAC's InvokerTransformer vulnerability?

Hi guys,

Recently, I've been researching about one vulnerability in the Apache Commons Collection library, related to deserialization of data coming from 'untrusted sources'. First, it is confusing to me what 'untrusted' stands for. I wouldn't say it is about the security layer, because to me it is more about 'safety' than trustness.

Anyway, the fact is that both gs-openspaces and hibernate core depends on this library, both as part of the XAP bundle. So, my point is: although I don't use this vulnerable class directly in my code, should I worry about it? Under the hoods, is XAP making use of it in any way that would make an processing unit insecure? Is there any report from Gigaspaces in this regard?

A link to contextualize the problem is here: www.kb.cert.org/vuls/id/576313

Cheers, Pedro

asked 2018-02-23 13:54:34 -0500

pedro_brigatto gravatar image
edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted

We've recently looked into this, and to the best of our knowledge we're not affected by this vulnerability, as we use custom serialization. In addition, commons-collection is only used by our JPA extension, so most of the time it's not even loaded.

To be on the safe side, and to obtain better security reports, we've recently upgraded to ACC 3.2.2, in which this vulnerability is resolved, and also moved the jar from lib/platform/commons to lib/optional/jpa, to explicitly denote where it's used. This is already committed and will be GA as part of the upcoming GA release.

If you wish, you can alter your existing XAP distro and drop-in ACC 3.2.2 instead of 3.2.1.


answered 2018-02-25 09:49:27 -0500

niv gravatar image
edit flag offensive delete link more

Thank you, Niv! Just one quick clarification ... what do you mean by JPA extension? The reason to the question is because we configure persistence in our space setup, and I'd like to confirm that this regular setup (example: setting a 'session factory' as org.springframework.orm.hibernate4.LocalSessionFactoryBean, pointing to the packages to scan, setting the data souce, etc) is not subject to this extension, but some sort of built-in mechanism for persistence.

In other words, I'd put an assumption: by using the standard persistence settings in the space configuration, as explained in the documentation, I'm not exposed to the vulnerability. Is this correct? In which circumstances I'd be exposed?

Thanks again for the support. :)

Best regards, Pedro

answered 2018-02-26 06:57:57 -0500

pedro_brigatto gravatar image
edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2018-02-23 13:54:34 -0500

Seen: 52 times

Last updated: Feb 26