131–140 of 157 posts
Earlier quoted context omitted.
That only works because Python is an interpreter. Won't cause a thing on Java.
The JRE has had arbitrary code execution attacks on serialization. The leaked classes eventually invoke a class loader and instantiate your binary code as a new java class.
Earlier quoted context omitted.
There are plenty of other options though, such as JSON, MessagePack, Protocol Buffers etc. And BinaryFormatter has always performed poorly against 3rd party libs, especially other binary formatters such MessagePack
Do any of these options support proper handling of cycles in the object graph out of the box?
Using the Newtonsoft library you can configure it using `JsonSerializerSettings.ReferenceLoopHandling`, and with with protobuf-net you set `AsReference` on your class's `ProtoContractAttribute`. I don't think MessagePack-CSharp or msgpack-cli support cyclic references tho.
Earlier quoted context omitted.
There's really no such thing as a "binary object graph format." Objects are not data. Code is not data. It's why serializing objects is so very complicated and dangerous. Serialized "data" is a program that can do everything a normal Java program can do. In the 90s we called this feature "mobile code" and thought it might be the future of distributed computing. Today we call it a "code injection attack" and recognize…
> Code is not data Lisp would, of course, disagree. :-)
(define data '(display code))
(define code (let ((pe primitive-eval)) (match data ((fun arg ...) (lambda () (apply (pe fun) arg))))))
(code)
Earlier quoted context omitted.
Regarding YAML, it's not just Ruby: * Python's yaml.load() hapilly executes arbitrary code. * Some Perl YAML libraries deserialize objects by default: http://blogs.perl.org/users/tinita/2018/02/safely-load-untru...
Python's YAML libraries come with a safe_load function that disables !! commands, so it can be used without loading arbitrary objects.
Can someone briefly explain the problems and how general they are to other serialization interfaces?
> and how general they are to other serialization interfaces? This class of problems was very common when that serialization appeared in Java. It was possible to inject code into pretty much anything, e-mails (1), office documents (2), web pages. Since that time, most developers / managers have learned their lesson and started to pay attention / allocate resources so modern software/protocols/formats tend to be more…
I applaud the general decision, but I wonder what will happen to existing blobs of serialized data. Will there be any migration tools provided? Apart from the horrible security, what annoyed me the most with serialization is the lack of control you have over the process. There doesn't seem to be a way to access serialized data as a simple parse tree or record sequence - you have to construct objects of the actual cla…
Many other language-specific serialization mechanisms just write arbitrary binary data into stream which can then only be parsed by ad-hoc recursive descent parser implemented by equivalent of java's readObject().
Earlier quoted context omitted.
There's really no such thing as a "binary object graph format." Objects are not data. Code is not data. It's why serializing objects is so very complicated and dangerous. Serialized "data" is a program that can do everything a normal Java program can do. In the 90s we called this feature "mobile code" and thought it might be the future of distributed computing. Today we call it a "code injection attack" and recognize…
There's no such thing as "data". Every piece of "data" eventually gets interpreted, thus becoming a "command" in some level of abstraction. The core of every security vulnerability is the belief that "this is just a piece of data".
RMI required it. Mr. Reinhold has apparently forgotten the scene in late 90s. CORBA anyone?
I applaud the general decision, but I wonder what will happen to existing blobs of serialized data. Will there be any migration tools provided? Apart from the horrible security, what annoyed me the most with serialization is the lack of control you have over the process. There doesn't seem to be a way to access serialized data as a simple parse tree or record sequence - you have to construct objects of the actual cla…
There's really no such thing as a "binary object graph format." Objects are not data. Code is not data. It's why serializing objects is so very complicated and dangerous. Serialized "data" is a program that can do everything a normal Java program can do. In the 90s we called this feature "mobile code" and thought it might be the future of distributed computing. Today we call it a "code injection attack" and recognize…
Earlier quoted context omitted.
> and how general they are to other serialization interfaces? This class of problems was very common when that serialization appeared in Java. It was possible to inject code into pretty much anything, e-mails (1), office documents (2), web pages. Since that time, most developers / managers have learned their lesson and started to pay attention / allocate resources so modern software/protocols/formats tend to be more…
Except that (1) was completely normal executable program (albeit in not well-known "format", which windows has many) and was not in any way executed automatically (and has nothing to with Java). And (2) is VBA macro virus which again has nothing to do with Java.
Both that VBS, and DOC/XLS, contain some code inside. But users though they are just data files, so they opened these things, running the code.
Also, old MS office files were not limited to embedded VBA. They are OLE compound files, so a specially crafted file can create and run ActiveX objects (often implemented as Win32 DLLs registered under HKEY_CLASSES_ROOT key of the registry) installed on user’s system. This is very similar to the way Java serializer creates and runs objects when desterilizing data received from untrusted source.