[perl-PlRPC] Document the Storable and encryption is not secure
Petr Pisar
ppisar at fedoraproject.org
Tue Nov 26 13:09:18 UTC 2013
commit b9497b8d780a54ff5be6661c5f24d70135e0bb79
Author: Petr Písař <ppisar at redhat.com>
Date: Tue Nov 26 14:08:09 2013 +0100
Document the Storable and encryption is not secure
...urity-notice-on-Storable-and-reply-attack.patch | 105 ++++++++++++++++++++
perl-PlRPC.spec | 9 ++-
2 files changed, 113 insertions(+), 1 deletions(-)
---
diff --git a/perl-PlRPC-0.2020-Security-notice-on-Storable-and-reply-attack.patch b/perl-PlRPC-0.2020-Security-notice-on-Storable-and-reply-attack.patch
new file mode 100644
index 0000000..877e7bc
--- /dev/null
+++ b/perl-PlRPC-0.2020-Security-notice-on-Storable-and-reply-attack.patch
@@ -0,0 +1,105 @@
+From 29f5ad4805a04e4c4fd18795f7153798c80a46ce Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= <ppisar at 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 at 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
+
diff --git a/perl-PlRPC.spec b/perl-PlRPC.spec
index 597550d..63997b3 100644
--- a/perl-PlRPC.spec
+++ b/perl-PlRPC.spec
@@ -1,6 +1,6 @@
Name: perl-PlRPC
Version: 0.2020
-Release: 15%{?dist}
+Release: 16%{?dist}
License: GPL+ or Artistic
Group: Development/Libraries
Summary: Interface for writing PlRPC clients and servers
@@ -8,6 +8,9 @@ Url: http://search.cpan.org/dist/PlRPC
Source: http://search.cpan.org/CPAN/authors/id/M/MN/MNOONING/PlRPC/PlRPC-%{version}.tar.gz
# See <https://rt.cpan.org/Public/Bug/Display.html?id=74430>
Patch0: %{name}-0.2020-Do-not-use-syslog.patch
+# Document the Storable and encryption is not secure, bug #1030572,
+# CPAN RT#90474
+Patch1: %{name}-0.2020-Security-notice-on-Storable-and-reply-attack.patch
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
# perldoc utility is called from Makefile
@@ -38,6 +41,7 @@ defining a set of methods that may be executed by the client.
%prep
%setup -q -n PlRPC
%patch0 -p1
+%patch1 -p1
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
@@ -57,6 +61,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Tue Nov 26 2013 Petr Pisar <ppisar at redhat.com> - 0.2020-16
+- Document the Storable and encryption is not secure (bug #1030572)
+
* Sun Aug 04 2013 Fedora Release Engineering <rel-eng at lists.fedoraproject.org> - 0.2020-15
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
More information about the scm-commits
mailing list