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?= +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ř +--- + 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 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 module is ++exercised before checking user password. ++ + =item perlsec + + And just in case I forgot it: Read the C 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 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 - 0.2020-16 +- Document the Storable and encryption is not secure (bug #1030572) + * Sun Aug 04 2013 Fedora Release Engineering - 0.2020-15 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild