Attachment 829254 Details for Bug 1030572 – Proposed documentation fix 2

[patch] Proposed documentation fix 2

0001-Security-notice-on-Storable-and-reply-attack.patch (text/plain), 3.75 KB, created by Petr Pisar on 2013-11-26 13:01:27 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Petr Pisar

Created: 2013-11-26 13:01:27 UTC

Size: 3.75 KB

patch

obsolete

>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
>

Actions: View | Diff

Attachments on bug 1030572: 825551 | 825588 | 825589 | 829254