| 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 |
| |