Skip Menu |
 

This queue is for tickets about the PlRPC CPAN distribution.

Report information
The Basics
Id: 90474
Status: new
Priority: 0/
Queue: PlRPC

People
Owner: Nobody in particular
Requestors: ppisar [...] redhat.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Security notice on Storable and reply attack
Download (untitled) / with headers
text/plain 462b
Florian Weimer pointed <https://bugzilla.redhat.com/show_bug.cgi?id=1030572> that PlRPC has two security flaws: (1) It uses Storable which is not suitable for crossing trust boundaries <http://search.cpan.org/~ams/Storable-2.45/Storable.pm#SECURITY_WARNING>. (2) The encryption support via cipher attribute does not protect from replay attacks because it encrypts payload without any serial number or a time stamp. Attached patch documents these deficiencies.
Subject: 0001-Security-notice-on-Storable-and-reply-attack.patch
From 5176840a8e2ed8e92583cbb99ae590aff452bfaa 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 | 10 ++++++++++ lib/RPC/PlServer.pm | 10 ++++++++++ 2 files changed, 20 insertions(+) diff --git a/README b/README index 8a68657..86054a7 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" @@ -263,6 +264,12 @@ 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 unauthorized connections. + perlsec And just in case I forgot it: Read the "perlsec" man page. :-) @@ -283,6 +290,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..3afd93d 100644 --- a/lib/RPC/PlServer.pm +++ b/lib/RPC/PlServer.pm @@ -637,6 +637,13 @@ 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 unauthorized connections. + =item perlsec And just in case I forgot it: Read the C<perlsec> man page. :-) @@ -667,6 +674,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
From: ppisar [...] redhat.com
Download (untitled) / with headers
text/plain 213b
Dne Po 18.lis.2013 06:32:04, ppisar napsal(a): Show quoted text
> Florian Weimer pointed > <https://bugzilla.redhat.com/show_bug.cgi?id=1030572> that PlRPC has > two security flaws: >
Attached patch provides better text. -- Petr
Subject: 0001-Security-notice-for-Proxy.patch
From cd8fcbbf402e1d70c9f325f8b0fcd99e02cf14be 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:52:09 +0100 Subject: [PATCH] Security notice for Proxy MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit PlRPC is not secure due to Storable. Warn Proxy users about it. Signed-off-by: Petr Písař <ppisar@redhat.com> --- lib/DBD/Proxy.pm | 7 +++++++ lib/DBI/ProxyServer.pm | 7 +++++++ 2 files changed, 14 insertions(+) diff --git a/lib/DBD/Proxy.pm b/lib/DBD/Proxy.pm index 287b2dc..5948255 100644 --- a/lib/DBD/Proxy.pm +++ b/lib/DBD/Proxy.pm @@ -974,6 +974,13 @@ The workaround is storing the modified local copy back to the server: $dbh->{"csv_tables"} = $tables; +=head1 SECURITY WARNING + +L<RPC::PlClient> used underneath is not secure due to serializing and +deserializing data with L<Storable> module. Use the proxy driver only in +trusted environment. + + =head1 AUTHOR AND COPYRIGHT This module is Copyright (c) 1997, 1998 diff --git a/lib/DBI/ProxyServer.pm b/lib/DBI/ProxyServer.pm index 68ad4af..78a0d78 100644 --- a/lib/DBI/ProxyServer.pm +++ b/lib/DBI/ProxyServer.pm @@ -867,6 +867,13 @@ Don't try to put parameters into the sql-query like this: =back +=head1 SECURITY WARNING + +L<RPC::PlServer> used underneath is not secure due to serializing and +deserializing data with L<Storable> module. Use the proxy driver only in +trusted environment. + + =head1 AUTHOR Copyright (c) 1997 Jochen Wiedmann -- 1.8.3.1
From: ppisar [...] redhat.com
Download (untitled) / with headers
text/plain 339b
Dne Po 18.lis.2013 08:00:29, ppisar napsal(a): Show quoted text
> Dne Po 18.lis.2013 06:32:04, ppisar napsal(a):
> > Florian Weimer pointed > > <https://bugzilla.redhat.com/show_bug.cgi?id=1030572> that PlRPC has > > two security flaws: > >
> Attached patch provides better text. >
I'm sorry, I attached wrong patch. This one should be correct. -- Petr
Subject: 0001-Security-notice-on-Storable-and-reply-attack.patch
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


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.