You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
106 lines
3.8 KiB
106 lines
3.8 KiB
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
|
|
|