SpringFramework utilizza InvokerTransformer da commons.collections?

Question

ha annunciato ieri su vulnerabilità deserializzazione (CVE-2015-4852):

https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread

Spring Framework utilizza commons.collections.

Se SpringFramework utilizza InvokerTransformer può essere vulnerabile per la vulnerabilità di serializzazione (CVE-2015-4852).

La domanda SpringFramework utilizza InvokerTransformer da commons.collections?

Answer 1

3. Aggiornare: Che è la risposta di Jürgen Höller alla mia Jira issues:

Spring Framework non usa Commons Collezioni in alcun modo. Se hai nel tuo classpath, potrebbe essere dietro un'altra dipendenza che hai scelto, come OpenJPA.

Detto questo, abbiamo un problema correlato in SPR-13656 in cui siamo stati fissando una nostra classe al fine di prevenire l'abuso in tali scenari. Si noti che ciò è importante solo se si espongono endpoint basati su serializzazione a client non attendibili. Spring non esegue tale esposizione per impostazione predefinita; è piuttosto qualcosa che la tua applicazione è esplicitamente optando per l'uso di HTTP Invoker o RMI Invoker.

Juergen

---

2. Aggiornamento: versione Spring Framework 4.2.3 e 4.1.9 aren't vulnerable ad un problema correlato.

---

ho cercato il progetto spring-framework e non ha trovato alcun uso di org.apache.commons.collections.(Transformer|InvokerTransformer|MapTransformer) finora. Ciò non significa che alcuni sottoprogetti Spring utilizzano InvokerTransformer.

Una rapida ricerca su jira.spring.io non ha rivelato problemi in questo momento:

https://jira.spring.io/issues/?jql=text%20~%20%22invoketransformer%22

https://jira.spring.io/issues/?jql=text%20~%20%22CVE-2015-4852%22

Forse un funzionario Pivotal può chiarire questo.

Aggiornamento: ho archiviato uno Jira issues.

Answer 2

Credo che la domanda non sia quella giusta.

La buona domanda per questo CVE è: è raccolta di apache commons nel classpath?(più specificamente InvokerTransformer)

Se la risposta è sì, l'applicazione è definitivamente vulnerabile se deserializza oggetti da qualsiasi tipo di fonti non sicure.

Se la risposta è no, l'applicazione non è vulnerabile a Invokertransformer CVE, ma è ancora potenzialmente vulnerabile ad altro tipo di hack se è ancora la deserializzazione di oggetti provenienti da fonti non attendibili senza controlli adeguati.

Il problema deriva principalmente dalle funzionalità di serializzazione e deserializzazione ... Quindi InvokerTransformer è solo la parte visibile dell'iceberg delle pratiche non sicure. Tuttavia, quello è un grande e semplice successo.

Deserializzare oggetti quando la versione serializzata non è sotto controllo significa decomprimere le scatole magiche.