Bug #90474 for PlRPC: Security notice on Storable and reply attack

Dne Po 18.lis.2013 08:00:29, ppisar napsal(a): Show quoted text
I'm sorry, I attached wrong patch. This one should be correct. -- Petr

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