SerializableTypeWrapper.MethodInvokeTypeProvider can be exploited for unsafe deserialization [SPR-13656]

[spring-projects-issues]

Yanming Zhou opened SPR-13656* and commented

http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
https://github.com/frohoff/ysoserial

---

Affects: 4.1.8, 4.2.2

Issue Links:

• Does Spring Framework use InvokerTransformer from Apache Collections? [SPR-13675] #18250 Does Spring Framework use InvokerTransformer from Apache Collections?

Backported to: 4.1.9

0 votes, 16 watchers

[spring-projects-issues]

Juergen Hoeller commented

I do not see why TypeProvider's serializability itself would be an issue here: It is an interface which is serializable by design, typically for purposes within the application (distributed sessions etc).

Are you possibly concerned about the inner MethodInvokeTypeProvider implementation?

[spring-projects-issues]

Juergen Hoeller commented

I suppose you're referring to this one, which is indeed based on MethodInvokeTypeProvider:

https://github.com/frohoff/ysoserial/blob/master/src/main/java/ysoserial/payloads/Spring1.java

I've renamed this issue accordingly, making it specifc to the MethodInvokeTypeProvider impl.

[spring-projects-issues]

Juergen Hoeller commented

It looks like we should guard the potential method names and/or target types handled by MethodInvokeTypeProvider, since it is only really meant to be used with common standard Type variants for our purposes there. Narrowing its capabilities to its actual intentions seems to be appropriate, preventing that kind of pretty fancy Type-faking exploit to be possible in the first place.

However, note that the only really safe measure is to not use object serialization at application entry points to begin with. In Spring land, this means that you shouldn't be using HTTP Invoker or RMI Invoker but rather REST endpoints with JSON payloads or the like. We are not accepting serialized input anywhere out of the box, so this is really a measure to be taken at the application level.

[spring-projects-issues]

Juergen Hoeller commented

Fixed for 4.2.3 now, and to be backported to 4.1.9. We're lazily invoking the method in MethodInvokeTypeProvider now which is itself sufficient for our purpose here since a deserialization exploit relies on the invocation to happen within readResolve() which does not happen anymore. Additionally, we're validating that the resolved method reference in readResolve() itself points to a method which returns Type or Type[], as expected.

Juergen

[spring-projects-issues]

Yanming Zhou commented

I really like HttpInvoker for SOA rather than REST with JSON.
I confirmed ea2843e have fixed this.

[spring-projects-issues]

Gil Collins commented

Does this issue exist in prior versions of the Spring Framework or is it strictly limited to 4.1.8 and 4.2.2 ?

Thank you

[spring-projects-issues]

Juergen Hoeller commented

The original form of SerializableTypeWrapper.MethodInvokeTypeProvider exists in all Spring Framework 4.x versions. However, since the only actively maintained lines are 4.1.x and 4.2.x at this point, we'll only be releasing the refined variant in 4.1.9 and 4.2.3.

As for our advice about not accepting Java serialization to begin with, note that this is about untrusted clients. HTTP Invoker within a trusted server system is not an issue; it's just about Java serialization based endpoints that can be accessed by anyone out there.

Juergen

[spring-projects-issues]

Gil Collins commented

One final question, should someone wanting to fix this issue take the snapshot or wait for the GA?

[spring-projects-issues]

Juergen Hoeller commented

Feel free to use 4.2.3.BUILD-SNAPSHOT for the time being; it's almost ready for release anyway. The actual release will follow by Monday November 16th.

This hasn't been backported to 4.1.9 yet, so doesn't appear in the snapshots there yet. We'll do a comprehensive backporting effort for 4.1.9 later this week.

Juergen

[spring-projects-issues]

Tim Farley commented

Is there a CVE number assigned to this issue? That's important so consumers of Spring will be aware this issue was fixed and that they should patch to close any associated security holes.

[spring-projects-issues]

Mark commented

4.2.3 has been released and is available. But when will 4.1.9 be available? From CAMEL-9402

Use Camel 2.17.x which will be spring 4.2.x based. Camel 2.16 is on spring 4.1. So the spring guys need to do a 4.1.9 release with the security fix.

[spring-projects-issues]

Juergen Hoeller commented

This has been backported to 4.1.x a few weeks ago already and is therefore available in the 4.1.9.BUILD-SNAPSHOT jars. As for the release date, we're aiming for next week; Thursday Dec 17th at the latest.

FWIW, as far as we are aware, a common Spring 4.1.x based application can be smoothly upgraded to 4.2.x simply through a version change in your POM. This applies for Boot 1.2.x applications as well which are technically on Spring 4.1.x but also work with 4.2.x; and it should also apply in combination with the use of Camel 2.16. Are there any upgrade issues?

Juergen

[spring-projects-issues]

Juergen Hoeller commented

Actually, it would be of great help to us if you could test the latest 4.1.9.BUILD-SNAPSHOT in anger! Even in combination with Camel 2.16 etc. Let's make sure that this release actually does the job for everybody involved, with no integration regressions. This is particularly important since 4.1.9 will be the last 4.1.x release; the next upgrade step will be 4.2.5.

Juergen

[spring-projects-issues]

Chris Feldhacker commented

Is there a CVE number for this issue? Can one be created?
Sonatype is asserting this vulnerability has a severity of 9.0:
https://support.sonatype.com/hc/en-us/articles/213733638-Spring-core-unintended-code-execution-in-deserialization

[spring-projects-issues]

Juergen Hoeller commented

There's no CVE number that I'm aware of, since this hasn't been reported through the regular vulnerability channels. It rather just got published in an attention-seeking article.

That aside, we strongly recommend against exposing serialization-based endpoints to untrusted clients. The real vulnerability are such endpoints in concrete applications: The misuse of specific classes on the classpath is a tool to break those endpoints, and Spring's MethodInvokeTypeProvider is just one class that somebody decided to speak about...

Once again, only applications with public endpoints that accept Java serialization from untrusted clients are affected. Any such severity rating would only apply under that condition.

Juergen