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.
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.
Real developers use an XML or JSON reader instead of using direct deserialization. Trust me I've built systems both ways and deserialization directly into objects is no bueno. You end up with more problems with version compatability alone to negate the benefits. There are also performance issues as well.
We'll make great pets
This is a programming problem that can happen anywhere. No language is immune. No project is automatically secure from exploits, or able to patch framework universally for all deployments.
Java and .NET will always have security issues, along with literally every other programming language. Anyone shocked, surprised, upset, or hostile to that concept is in the wrong profession.
Assume everything is compromised. Assume nothing is secure. Design around that assumption and you will survive.
prevent deserialized data from accessing and running certain methods automatically
How exactly does data access anything?
Extract data via methods, using strings, and populate your objects manually.
Using direct xml to hard-coded class fields is a nightmare. Changing the field name breaks deserialization.
Completely agree. We used .net binary serialization/deserialization because it was such a quick way to get things up and running...with like two lines of code. The fact that the serialized objects were about 10x bigger than they needed to be was not a problem.
It turns out the namespaces are included in the serialized data, so the moment we did an ounce of lightweight refactoring we broke it. It took us less than a day to write our own serializer, but an extra three days of combined manpower to get a format converter built and deployed.
We would have saved all that if we had just started with our own serializer.
Prefab solutions to simple problems are a deal with the devil. Beware!
I'm kind of surprised this hasn't already built into a more prominent issue over time.
Performance issues I can stomach - there's going to be some unavoidable parsing logic no matter how you go at translating from runtime to storage or network logic - but instead, large swaths of objects just get ignored in major libraries. When using unity, for instance, can't serialize dictionaries, and many other objects in the default serializer - which is a major oversight.
Google actually has provided some rather nice tools to help with this - I tend to use their 'Protocol buffer' libraries for their rather nice serialization options. This doesn't address security on its own - nothing does completely, but designing careful locked signal processing and independent cross-checking steps can help a lot. Well-salted encryption alone won't really save you.
My pet peeve with protocol buffers the need to give everything an index number, with no real auto-numbering for rapid design - I can see the logical need, to be able to rely on that order for processing - it's just an extra babysitting step that gets me sometimes. For what it does, it's still the best I've found to be consistent between diverse projects and still leaving room for decent security.
Ryan Fenton
Google engineers banded together in their 20% time.
Peter predicted that you would "deliberately forget" creation 2000 years ago...
Walking a data tree is 1st year CS level work. If you're spending half your efforts on it then you're either vastly short on resources or your coders suck donkey balls.
Personally I think "exposing" objects is the problem. Your border should be a mailbox that exchanges messages and those messages should be inspected carefully before internal delivery. I have no idea why people want to dump a class they wrote onto a live internet service and just hope that it dumps data into the correct table somewhere. They dragged the "security api" icon onto the project space so it's secure.
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.
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.
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
http://www.theregister.co.uk/2017/08/11/malware_in_dna/ triggering buffer overflow. Perhaps NOT the best example b ut the point's there.
Buffer overflow (data driven) is the point though.
APK
P.S.=> "Garbage in/garbage out" is an old saying about data too - misinformation & disinformation? Another... apk
No language is immune
That's a pretty broad generalization to be making. There's a good possibility that a safe-by-default language like Rust wouldn't be susceptible. It doesn't even have legacy objects like Java and C# have. Rust is also statically typed, and it enforces thread safety and memory safety.
You're absolutely right. A lot of people here are missing the fact that it's not a serialization problem, it's a programming language problem. This is what happens when dynamic languages, which these days include Java and C# even if they are compiled to some degree, are used instead of a static language like Rust that guarantees memory and thread safety.
Can someone explain what the problem is here? Serialized objects are just code, and if you're running untrusted code you've got bigger problems than bugs in your serialization libraries.
If marshalling objects exposes privatized members of your objects it's "houston, we have a problem" - fix it.
* My preferred "weapon of choice" compiled statically (can be runtime driven but I avoid performance hits this way) Delphi stores object persistence in its .DFM file so that they are consistent & reload "on the fly" (no problems like this afaik, UNLESS you were to use .NET in Delphi apparently, which yes, you can (funniest part about that is Delphi had .NET working in it before MS comiplers did)).
It's a SMART & LONG PROVEN safer high-performance language (beat the shit out of Java, MSVC++ where it matters in what's MOST used, all programs do some math & strings as far back as 1997 in of all places, "Visual Basic Programmers Journal" Sept issue "INSIDE THE VB5 COMPILER ENGINE" issue where they ADMITTED it kicked the crap out of them both, even DOUBLING C++ performance there) & unlike say, C/C++? It's also not prone to buffer overflows like C/C++ are (string length is incorporated in Delphi's strings)
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
P.S.=> THIS is WHY I avoid using others' 3rd party libs (other than OS apis) WHEN/IF possible - something always "turns up" in them that's rotten sooner or later & you're vulnerable/exposed UNTIL THE VENDOR of said lib/dlll (or interpreter engine) ISSUES A FIX (IF they do) - e.g.: SQLite. I could've used it in APK Hosts File Engine 9.0++ SR-7 32/64-bit but it turned up a decade++ long issue recently & it's written in C (iirc)... apk
They aren't part of. Net itself, just third party libraries.
Tired of my customary (Score:1)
REST is not object oriented, for all the reasons you pointed out. ;-)
It's just an RPC (remote procedure call) interface, but highly restricted on the encoding and selection of the procedures. The whole "all procedures must correspond to Create, Read, Update, or Delete" is an inappropriate joke a lot of the time. But we shoehorn it in and make it fit!
Add something like an Authenticating Hash that depends on a secured secret (eg. Cert that is installed in non-removal mode in window slls store. Run the check on the binary stream of JSON before using JSON deserializer type inference. Alternatively, maybe add JSON schema to validate first... or be explicit with the expected types for what is being deserialised...so no type inference is used. N.B. i haven't read the paper yet...but will in a few hrs time. So i could possibly amend this comment.
As stated int he linked document, for JSON.NET to be vulnerable, you have to explicitly set an option making it less secure.
As with encryption and security libraries, you are better off using well-established libraries like JSON.NET than rolling your own. A solo developer, or corporate team, just doesn't have the resources or time to work out all the security vulnerabilities, as can be done with a dedicated library.
trained by CRAP people.
A commerce site I recently used rejected my credit card because a 5+4 ZIP code couldn't be parsed. WTF!!!!
Dumping the class is faster and easier than creating, sending, then parsing and validating messages. But I agree with you. Most of the software I write is completely message based. That model works well.
This is not surprising ! We discovered recently some "billion-laughs"-style DOS attacks that exploit vulnerabilities in Java, and ported some of them to .NET and Ruby. Details here:
http://drops.dagstuhl.de/opus/... (paper, there is also an artefact to run attacks in a VM), and the source code is here: https://bitbucket.org/jensdiet... .
We did have some problems porting this from Java to .NET but managed eventually. Interestingly, some of these problems were caused by a bug in .NET: a broken contract between equals and hashcode (see https://github.com/dotnet/core...) .
Walking a data tree is 1st year CS level work. If you're spending half your efforts on it then you're either vastly short on resources or your coders suck donkey balls.
Correct and then 2nd year CS work is red/black trees and other advanced algorithms. The whole time you're learning this you're taking increasingly higher levels of mathematics. You see the problem I run into is that many people couldn't make it to the 2nd year in Computer Science and went into Information Technology or some other "Computer Science Lite" field of study. These are the majority of people in the field now that really lack to ability to understand the difference between different implementations logically and mathematically. Computer Science is a hard degree. It's called Computer _SCIENCE_ for a reason.
We'll make great pets
Too bad all you can ever manage is shit toy problems.
Please tell me about how you created hosts file engine cocksucker edition and how the Chinese copied you and not every other person who has done the same but better and/or earlier.
Please provide a bunch of quotes from people that no one can find or you have taken out of context.
Actually I really want you to whine and bitch about AC posts since you are just a whiny little bitch.
I'm not one to advocate for fashion in computer languages, but Lisp? Really?
Lisp had it's shot. If Lisp ideas were going to dominate, or even just achieve some niche popularity, it would have done so by now. Lisp has had way, way over a half century to achieve commercial popularity and it has not done so. Lisp is a niche even in academia!
Geezus, Cold Fusion had more popularity. BASIC had more relevance. Clipper/dBase/FoxPro had more commercial relevance. Focus had more customers.
Lisp??