From ba20e4ab7425ecd36531d965b5a237c015db2bb2 Mon Sep 17 00:00:00 2001 From: Steffen Mueller Date: Fri, 30 Nov 2012 23:03:09 -0500 Subject: [PATCH] add a note about security concerns in Storable Storable is not a great way to pass data back and forth across security boundaries. We have discussed the security implications of the auto-loading and auto-blessing behaviors in Storable in the past, both on the perl5-porters mailing list and at various conferences. Somehow, though, these "well-known" probably have never actually been put into the documentation. This patch corrects that. The original version of this patch included a recommendation to use Sereal in its most stringent configuration, but that text was removed for the time being by Ricardo Signes, who hopes to add it back once Sereal has been in public use for just a bit longer. --- ext/Storable/Storable.pm | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/ext/Storable/Storable.pm b/ext/Storable/Storable.pm index 20df4f1..a086d08 100644 --- a/ext/Storable/Storable.pm +++ b/ext/Storable/Storable.pm @@ -1017,6 +1017,38 @@ compartment: =for example_testing is( $code->(), 42 ); +=head1 SECURITY WARNING + +B + +Some features of Storable can lead to security vulnerabilities if you +accept Storable documents from untrusted sources. Most obviously, the +optional (off by default) CODE reference serialization feature allows +transfer of code to the deserializing process. Furthermore, any +serialized object will cause Storable to helpfully load the module +corresponding to the class of the object in the deserializing module. +For manipulated module names, this can load almost arbitrary code. +Finally, the deserialized object's destructors will be invoked when +the objects get destroyed in the deserializing process. Maliciously +crafted Storable documents may put such objects in the value of +a hash key that is overridden by another key/value pair in the +same hash, thus causing immediate destructor execution. + +In a future version of Storable, we intend to provide options to disable +loading modules for classes and to disable deserializing objects +altogether. I + +B + +If your application requires accepting data from untrusted sources, you +are best off with a less powerful and more-likely safe serialization format +and implementation. If your data is sufficently simple, JSON is a good +choice and offers maximum interoperability. + =head1 WARNING If you're using references as keys within your hash tables, you're bound