Login
[x]
Log in using an account from:
Fedora Account System
Red Hat Associate
Red Hat Customer
Or login using a Red Hat Bugzilla account
Forgot Password
Login:
Hide Forgot
Create an Account
Red Hat Bugzilla – Attachment 829254 Details for
Bug 1030572
perl-PlRPC: not secure across trust boundaries
[?]
New
Simple Search
Advanced Search
My Links
Browse
Requests
Reports
Current State
Search
Tabular reports
Graphical reports
Duplicates
Other Reports
User Changes
Plotly Reports
Bug Status
Bug Severity
Non-Defaults
|
Product Dashboard
Help
Page Help!
Bug Writing Guidelines
What's new
Browser Support Policy
5.0.4.rh83 Release notes
FAQ
Guides index
User guide
Web Services
Contact
Legal
This site requires JavaScript to be enabled to function correctly, please enable it.
[patch]
Proposed documentation fix 2
0001-Security-notice-on-Storable-and-reply-attack.patch (text/plain), 3.75 KB, created by
Petr Pisar
on 2013-11-26 13:01:27 UTC
(
hide
)
Description:
Proposed documentation fix 2
Filename:
MIME Type:
Creator:
Petr Pisar
Created:
2013-11-26 13:01:27 UTC
Size:
3.75 KB
patch
obsolete
>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 >
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Diff
View Attachment As Raw
Actions:
View
|
Diff
Attachments on
bug 1030572
:
825551
|
825588
|
825589
| 829254