back to article Warning over Java libraries and deserialization security weaknesses

Boffins at universities in France, Germany, Luxembourg, and Sweden took a deep dive into known Java deserialization vulnerabilities, and have now resurfaced with their findings. In short, they've drawn attention to the ways in which libraries can accidentally introduce serious security flaws. Serialization is used to convert a …

  1. A Non e-mouse Silver badge
    Holmes

    NSS

    I’m a hobbyist Java programmer & I’ve been playing with Java for 10-15 years. Even I know that standard Java serialization is dangerous.

    If full-time Java programmers are using standard Java serialization, they really need to go back to school.

    This problem of object serialization being unsafe is not unique to Java. Other languages offer similar features and all give the same dire warnings: Don’t use it if you can’t trust the input.

    What’s one of the standard security warnings for programmers? Never trust user supplied input.

    1. Blazde

      Re: NSS

      The problem is that serialisation is awfully convenient.

      A well known MMOG - written in a non-Java language I won't mention because it would probably give the game away - uses serialisation for network communication. Many years ago I dug into it that part of it and quickly found a dozen separate vulnerabilities (some of them caused heap corruption, some just causing memory violations that would bring down the targetted client or server without taking it over, etc).

      The most egregious involved them allowing a limited set of method calls to be serialised. A sort of a la carte direct-'gadget' menu. My creative juices began flowing dreaming up the most majestic exploit that could be written with such tools. Of all the possibilities for combining them which would I choose? But the inventive process was cut short when one of the methods turned out to be "Hey, run this arbitrarily long string of code for me please".

      The more difficult problem was how to get across to the company the breadth of the problem. You could see why they'd done it, apart from the gaping security issue, the architecture was powerful but clean. You could abstract really complex object behaviour, throw the object across a TCP connection or some shared memory to another process, put it in a database, and retrieve it years later when your codebase had moved on, all without caring much what the object was in the first place. Knowing the genesis of the game, how rapidly it was prototyped with so few developers, it's quite likely it wouldn't have come to market without some form of serialisation of untrusted input. And the world would be a poorer place for that *shrug*

    2. Steve Channell
      Flame

      Re: NSS

      Not only has Java deserialization been a "bug" for twenty years (remote class loader enabled injections of arbitrary code into STRUTS a decade ago, and more recently with Log4J), it has been maintained as a "feature" to prevent IKVM and Android cross compilation of bytecode

  2. Anonymous Coward
    Boffin

    Sign of the Times

    We live in a time where many programmers are never taught the lessons of the past - like always verify your input data.

    Furthermore, too many programmers are unwilling (due to personal preferences or management directive) to spend time and money on security - hence the average of 6 years to remove gadgets.

    Given this, the boffins' finding are alarming but not surprising.

    1. Anonymous Coward
      Anonymous Coward

      No intended as a slap

      But the basic premise of Java was to make a language for programmers you couldn't trust based on a java VM that was built by programmers you could. This got turned inside out, as the JVM is bug ridden trash, and even a good programmer has a hard time coding around all the glaring issues.

      You gave up pointers for this mess, but as it still let's any newbie call "public static shoot(my.foot)" what's the point? It seems like Java gave up on the idea of user safe or programmer safe code, and is just fighting against change at this point. If it allows easy and unchecked security problems in deserialization, why block other useful operations based on the idea that their use is similarly risky? Inertia seems the clear choice. And as the community bleeds mind share to other platforms, it seems like that inertia is becoming an existential threat to the community.

      1. TheMeerkat Bronze badge

        Re: No intended as a slap

        I don’t think you understand anything about Java or the problem discussed.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like