mbraceproject / FsPickler

A fast multi-format message serializer for .NET
http://mbraceproject.github.io/FsPickler/
MIT License
323 stars 54 forks source link

(De)Serializer Attack Surface #94

Closed ghost closed 6 years ago

ghost commented 6 years ago

Hello, I am posting this a bit blind (I have searched on this repo's issue tracker and MBrace.Azure and have not found anything relating to this topic), recently (last few days) a talk was given at a security conference that mentioned .NET serialization vulnerabilities. FsPickler was especially mentioned, worryingly as an Example in the section referring to remote code execution.

The slide deck is available at https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-Json-Attacks.pdf, unfortunately I don't have any additional useful information about it (as I was not in attendance of this conference), but I thought I would bring it to someones attention (it might be worthwhile cc'ing in people from MBrace.Azure to ensure no interfaces are exposed that would allow an attacker to abuse untrusted input that gets deserialized by FsPickle).

eiriktsarpalis commented 6 years ago

Thanks. This is part of the core design of this library, in particular to provide the ability to serialize arbitrary lambdas to power mbrace. Now, deserializing lambdas is enabling arbitrary code execution no matter how you look at it, which is kind of the point in distributed compute frameworks like mbrace or Spark. So I don't see how this could ever be changed or "fixed".

I only wish that the authors would take more time to investigate the background and motivation behind each library (e.g. https://github.com/mbraceproject/Vagabond) rather than lumping together everything they could scavenge from github. The fact that people use FsPickler as if it's suitable to run in something like a webserver doesn't help either.

eiriktsarpalis commented 6 years ago

See also http://eiriktsarpalis.github.io/mbrace-msrc/#/19

ghost commented 6 years ago

Very good, indeed. There is now something searchable when people look for this issue! Perhaps it would avoid security authors of publishing false positives like this if FsPickler documentation provided a warning, much like python pickle (https://docs.python.org/2/library/pickle.html) to let everyone know that the library is not intended to be responsible for such things?

Edit: Just to clarify, while it is not FsPickler's responsibility to provide common sense, pickle libraries have had a long history of providing problems as people use them in silly ways, I wouldn't mind betting the authors googled /gitsearched for pickle, .net, objects

ghost commented 6 years ago

I think this has been answered and is definitely not an issue, closing! :)