izackp / autobuffer Goto Github PK

Someone on reddit mentioned the possibility of an exploit using polymorphism for an unintended class to be serialized.

ClassSerialize
|
ClassPleaseDontSerialize: ClassSerialize

I will need to add a specific 'opt-out' attribute for children or an attribute property on the type declaring to ignore children for serialization.

possible via FormatterServices.GetUninitializedObject ?

• See if the majority of languages support byte[] -> Struct
• Will also have to throw any endianess out and support Little Endian only (Only a few microcontrollers support BE).

Be aware even though TCP serialized in BE that doesn't mean it's content has to be, so it means very little as argument against it.. seemingly.

https://github.com/pwntester/ysoserial.net <- Common serialization exploits for .NET

Interfaces are broken. We need to compare the field type (type on the field/property) instead of using the actual type (type on the instance) to determine if we write/read metadata (aka type info).

Lets say you have a list of all the students in a school.
Lots of these students will have the same teacher.
If we serialize the student list and they all have the same teacher reference.. It would make sense to avoid being redundant. However, currently we just write directly to the buffer from front to back. Making some sort of 'reuse' list in the front would require making a new buffer.

We have a few options:
Keep a list of all created instances, and have a specific class 'SerializationReference' that holds an index to this cache of reference that will be resolved on deserialization. What's going to be slow is that we're going to have to 'hash' every single instance being serialized. Then we're going to have to perform a 'lookup' for the majority of deserializations.

Second option
Let the user handle it himself. You could create a serializable class called IdRef<T:iHasId> and each reference can hold an id. In the payload you could include a flat list of students and a flat list of teachers and resolve references as that property is accessed.

Third option
A combination of the above two. All serializable classes that implement iHasId could be 'flattened' then resolved. During deserialization we can store the first instance in typeInstanceTable[id] then check against it for all future instances.

Still thinking will come back to this.