Slashdot Mirror

← Back to Stories (view on slashdot.org)

Deserialization Issues Also Affect .NET, Not Just Java (bleepingcomputer.com)

Posted by EditorDavid on from the Apocalypse-.Net dept.

"The .NET ecosystem is affected by a similar flaw that has wreaked havoc among Java apps and developers in 2016," reports BleepingComputer. An anonymous reader writes: The issue at hand is in how some .NET libraries deserialize JSON or XML data, doing it in a total unsecured way, but also how developers handle deserialization operations when working with libraries that offer optional secure systems to prevent deserialized data from accessing and running certain methods automatically. The issue is similar to a flaw known as Mad Gadget (or Java Apocalypse) that came to light in 2015 and 2016. The flaw rocked the Java ecosystem in 2016, as it affected the Java Commons Collection and 70 other Java libraries, and was even used to compromise PayPal's servers.

Organizations such as Apache, Oracle, Cisco, Red Hat, Jenkins, VMWare, IBM, Intel, Adobe, HP, and SolarWinds , all issued security patches to fix their products. The Java deserialization flaw was so dangerous that Google engineers banded together in their free time to repair open-source Java libraries and limit the flaw's reach, patching over 2,600 projects. Now a similar issue was discovered in .NET. This research has been presented at the Black Hat and DEF CON security conferences. On page 5 [of this PDF], researchers included reviews for all the .NET and Java apps they analyzed, pointing out which ones are safe and how developers should use them to avoid deserialization attacks when working with JSON data.

5 of 187 comments (clear)

  1. Simpler solution by BarbaraHudson · · Score: 1, Insightful

    Just don't use JSON or XML. You can thank me later.

    --
    "Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
  2. Agree. by Anonymous Coward · · Score: 2, Insightful

    It appears that the market is flooded with developers who can write scripts but not algorithms. They believe that something like parsing JSON is really hard and complicated, that any home-grown solution to doing that will be extremely buggy and slow, all because they themselves haven't taken the mental step-up.

    Of course, this mental step-up used to be a standard part of a CS degree. College students would be writing code that does this sort of thing as homework. This has changed, and I have seen the change in the candidates we interview. I ask them questions about their courses in algorithms and what they did, and they say things like "we learned what the foundational algorithms are and how to compare their performance." Did you actually write a merge sort? "No, there's no need because every major language has that sort of thing built in."

    So, there's the rub. They paid good money for a degree that glanced over the most important bits. Naturally, they feel completely justified in their beliefs that stringing third-party solutions together is the best way to write code.

    And a whole new crop of these scripters hits the job market every year, more than we have seen in a decade. Colleges have been lowering the bar due to higher interest among students that aren't really cut out for it, that in turn due to successful social engineering on the part of the tech giants.

    At least, that's my hypothesis.

    1. Re:Agree. by Joviex · · Score: 4, Insightful

      I ask them questions about their courses in algorithms and what they did, and they say things like "we learned what the foundational algorithms are and how to compare their performance." Did you actually write a merge sort? "No, there's no need because every major language has that sort of thing built in."

      Consider me a cultist follower of your hypothesis. 20 years in CS, the last 10 I have seen it take a sharp dive. The only explanation I have is the explosion over 15 years ago in OSS and that what you espouse is true: Everyone thinks they can develop or engineer, because the code is tied up in nice little solution blocks.

      Need a sort algo? Just codeproject.com
      Need some bi-directional comm between remotes? Just github.com...etc....

      The number of people I have turned away in the first two days of testing, who could not even write a simple priority Q... its more than disheartening.

      These are the "developers" who are supposed to code my future? Fuck me! I'll be working till I die.

  3. JSON does not have code-execution ability by Anonymous Coward · · Score: 5, Insightful

    JSON only defines a bunch of basic data types. It defines no ability to run anything. These bugs are in (de)serialization layer above it, which uses JSON as a transport and extend the meaning of the data stored to be able to deserialize higher-level objects.

    JSON or XML are not the problem here. The same problem could happen if you serialized to CSV or TXT or anything else for that matter.

  4. Re: Not a .NET problem by peppepz · · Score: 3, Insightful

    The title is sensationalistic. Even the original bug the author talks about, calling it repeatedly a "Java" bug, was actually a bug in the Apache Commons Collections library, not in the platform, and it could only be triggered if a server using the library allowed customers to provide serialized data for itself to deserialize, which is severely wrong in the first place (it's akin to eval()-ing client-provided text).