add a note about security concerns in Storable
authorSteffen Mueller <smueller@cpan.org>
Sat, 1 Dec 2012 04:03:09 +0000 (23:03 -0500)
committerRicardo Signes <rjbs@cpan.org>
Tue, 4 Dec 2012 19:06:33 +0000 (14:06 -0500)
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.

dist/Storable/ChangeLog
dist/Storable/Storable.pm

index 351159c..31e1b0c 100644 (file)
@@ -1,3 +1,8 @@
+?
+    Version 2.40
+
+       Security warnings section added
+
 Tue 11 Sep 06:51:11 IST 2012   Abhijit Menon-Sen <ams@toroid.org>
     Version 2.39
 
index 668bf44..7d53454 100644 (file)
@@ -21,7 +21,7 @@ package Storable; @ISA = qw(Exporter);
 
 use vars qw($canonical $forgive_me $VERSION);
 
-$VERSION = '2.39';
+$VERSION = '2.40';
 
 BEGIN {
     if (eval { local $SIG{__DIE__}; require Log::Agent; 1 }) {
@@ -1019,6 +1019,38 @@ compartment:
 =for example_testing
         is( $code->(), 42 );
 
+=head1 SECURITY WARNING
+
+B<Do not accept Storable documents from untrusted sources!>
+
+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<Nonetheless, Storable deserializing documents from
+untrusted sources is expected to have other, yet undiscovered,
+security concerns such as allowing an attacker to cause the deserializer
+to crash hard.>
+
+B<Therefore, let me repeat: Do not accept Storable documents from
+untrusted sources!>
+
+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