|Subject:||Security notice on Storable and reply attack|
Florian Weimer pointed <> that PlRPC has two security flaws: (1) It uses Storable which is not suitable for crossing trust boundaries < . (2) The encryption support via cipher attribute does not protect from replay attacks because it encrypts payload without any serial number or a time stamp. Attached patch documents these deficiencies.
From 5176840a8e2ed8e92583cbb99ae590aff452bfaa Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= <email@example.com> Date: Mon, 18 Nov 2013 12:20:52 +0100 Subject: [PATCH] Security notice on Storable and reply attack MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Petr PÃsaÅ <firstname.lastname@example.org> --- README | 10 ++++++++++ lib/RPC/PlServer.pm | 10 ++++++++++ 2 files changed, 20 insertions(+) diff --git a/README b/README index 8a68657..86054a7 100644 --- a/README +++ b/README @@ -204,6 +204,7 @@ EXAMPLE require RPC::PlServer; require MD5; + package MD5_Server; # Clients need to request application # "MD5_Server" @@ -263,6 +264,12 @@ SECURITY Be restrictive Think twice, before you give a client access to a method. + Use of Storable + Storable module used for serialization and deserialization + underneath is inherently insecure. Deserialized data can contain + objects which lead to loading foreign modules and executing possible + attached destructors. Do not accept unauthorized connections. + perlsec And just in case I forgot it: Read the "perlsec" man page. :-) @@ -283,6 +290,9 @@ SECURITY authorized, you should switch to a user based key. See the DBI::ProxyServer for an example. + Please note PlRPC encryption does not protect from reply attacks. + You should have implement it on the application or the cipher level. + AUTHOR AND COPYRIGHT The PlRPC-modules are diff --git a/lib/RPC/PlServer.pm b/lib/RPC/PlServer.pm index 10b56c9..3afd93d 100644 --- a/lib/RPC/PlServer.pm +++ b/lib/RPC/PlServer.pm @@ -637,6 +637,13 @@ object handle is valid before coercing a method on it. Think twice, before you give a client access to a method. +=item Use of Storable + +L<Storable> module used for serialization and deserialization underneath is +inherently insecure. Deserialized data can contain objects which lead to +loading foreign modules and executing possible attached destructors. Do not +accept unauthorized connections. + =item perlsec And just in case I forgot it: Read the C<perlsec> man page. :-) @@ -667,6 +674,9 @@ login phase, where to use a host based key. As soon as the user has authorized, you should switch to a user based key. See the DBI::ProxyServer for an example. +Please note PlRPC encryption does not protect from reply attacks. You should +have implement it on the application or the cipher level. + =back =head1 AUTHOR AND COPYRIGHT -- 188.8.131.52