From 29f5ad4805a04e4c4fd18795f7153798c80a46ce Mon Sep 17 00:00:00 2001

From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= <ppisar@redhat.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ř <ppisar@redhat.com>

---

 README              | 16 ++++++++++++++++

 lib/RPC/PlServer.pm | 15 +++++++++++++++

 2 files changed, 31 insertions(+)

diff --git a/README b/README

index 8a68657..48a33e4 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"

@@ -245,6 +246,10 @@ SECURITY

     that I missed something. Security was a design goal, but not *the*

     design goal. (A well known problem ...)

+    Due to implementation of PlRPC, it's hard to use internal authentication

+    mechanisms properly to achieve secured remote calls. Therefore users are

+    advised to use an external authentication mechanism like TLS or IPsec.

+

     I highly recommend the following design principles:

   Protection against "trusted" users

@@ -263,6 +268,14 @@ 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 host-based unauthorized

+        connections. The Storable module is exercised before checking user

+        password.

+

     perlsec

         And just in case I forgot it: Read the "perlsec" man page. :-)

@@ -283,6 +296,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..ce38594 100644

--- a/lib/RPC/PlServer.pm

+++ b/lib/RPC/PlServer.pm

@@ -613,6 +613,10 @@ I did my best to avoid security problems, but it is more than likely,

 that I missed something. Security was a design goal, but not *the*

 design goal. (A well known problem ...)

+Due to implementation of PlRPC, it's hard to use internal authentication

+mechanisms properly to achieve secured remote calls. Therefore users are

+advised to use an external authentication mechanism like TLS or IPsec.

+

 I highly recommend the following design principles:

 =head2 Protection against "trusted" users

@@ -637,6 +641,14 @@ 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 host-based unauthorized connections. The L<Storable> module is

+exercised before checking user password.

+

 =item perlsec

 And just in case I forgot it: Read the C<perlsec> man page. :-)

@@ -667,6 +679,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

-- 

1.8.3.1