Slashdot Mirror
Deserialization Issues Also Affect .NET, Not Just Java (bleepingcomputer.com)
"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.
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.
See subject: When you design a class for your objects THAT is the point of "private" classification protection & apparently? It falls apart in these slower bugprone & NOT LIVING UP TO WHAT THEY SAID THEY WERE (safe) interpreted languages.
APK
P.S.=> As far as serialization & protection of these objects/classes member functions & data + consistency of reload again? See my other post & HOW what I tend to use most protects vs. it (no problem afaik to date in it either) & OTHER serious issues https://it.slashdot.org/comments.pl?sid=10984357&cid=55003119/ - however, if you want to "rig" C/C++ vs. buffer overflows I note there (like you have to rig C for errhandling)? Two pointers, 1 double the length of the 1st, sent thru a char array/string, can determine its length vs. that (when larger one no longer advances, you have midpoint & w/ that, you can determine string length easily (or use strlen functions etc. which IS probably that code RIGHT there in fact I'd wager (odd vs. even check too)) ... apk