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

[spring-projects-issues]

Juergen Hoeller commented

FYI, an article that essentially takes our perspective as well: http://www.javaworld.com/article/3003197/security/library-misuse-exposes-leading-java-platforms-to-attack.html

[spring-projects-issues]

Stephen J. Muir commented

Can someone elaborate on how this has been fixed please. For example, when the endpoint receives a serialized object, how does it know if it's got any classes in it which shouldn't be there.

[spring-projects-issues]

Juergen Hoeller commented

FWIW, from our perspective (and not just ours), the only proper fix is to not expose such endpoints to untrusted clients to begin with. Any other data representation - XML, JSON, custom data formats - is a way better choice for untrusted clients. Blacklisting of classes for serialization endpoints is never going to be a complete solution, and whitelisting is going to be a lot of pain to maintain. Other data formats provide a way better tradeoff overall and are very worth a refactoring. If you have to keep using serialization on your system boundary, make sure that those endpoints are only accessible to trusted clients and that interaction with them is properly logged (and therefore traceable after misuse).

As for this particular issue here, it's solely about tightening our MethodInvokeTypeProvider implementation so that it cannot be misused in such a serialization exploit anymore. So it's one class tightened up now that's commonly found on application classpaths, and that's a step forward. It's just also pretty certain that other such classes remain that nobody is aware of, or rather that nobody disclosed yet. Once again, do not accept serialized Java classes from untrusted classes to begin with; it's the only safe way out.

Juergen

[spring-projects-issues]

Nebula commented

hi, I just said that the actual use of this vulnerability, control a redis server is very easy, spring-data-redis able to remote code execution. no loopholes announcement developers will not know the existence of this problem.

[spring-projects-issues]

Juergen Hoeller commented

Nebula, fair enough. We released several notes to the effect of not exposing serialization-based endpoints to untrusted clients, and this seems to be a variant thereof. It's certainly worth making the Spring Data Redis team aware of the value serialization risk; however, I don't see a pending fix there other than recommending an upgrade to Spring 4.1.9+ and not configuring value serialization in such scenarios.

Juergen