Uploaded image for project: 'Spring Framework'
  1. Spring Framework
  2. SPR-13656

SerializableTypeWrapper.MethodInvokeTypeProvider can be exploited for unsafe deserialization

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Complete
    • Affects Version/s: 4.1.8, 4.2.2
    • Fix Version/s: 4.1.9, 4.2.3
    • Component/s: None
    • Labels:
      None
    • Last commented by a User:
      false

      Issue Links

        Activity

        Hide
        juergen.hoeller Juergen Hoeller added a comment -
        Show
        juergen.hoeller Juergen Hoeller added a comment - 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
        Hide
        sjmuir Stephen J. Muir added a comment -

        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.

        Show
        sjmuir Stephen J. Muir added a comment - 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.
        Hide
        juergen.hoeller Juergen Hoeller added a comment -

        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

        Show
        juergen.hoeller Juergen Hoeller added a comment - 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
        Hide
        nebula Nebula added a comment -

        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.

        Show
        nebula Nebula added a comment - 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.
        Hide
        juergen.hoeller Juergen Hoeller added a comment -

        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

        Show
        juergen.hoeller Juergen Hoeller added a comment - 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

          People

          • Assignee:
            juergen.hoeller Juergen Hoeller
            Reporter:
            quaff Yanming Zhou
            Last updater:
            Juergen Hoeller
          • Votes:
            0 Vote for this issue
            Watchers:
            16 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Days since last comment:
              1 year, 47 weeks ago