RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1030572 - perl-PlRPC: not secure across trust boundaries
Summary: perl-PlRPC: not secure across trust boundaries
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: perl-PlRPC
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: perl-maint-list
QA Contact: Martin Kyral
URL:
Whiteboard:
Depends On:
Blocks: 1030547 1051106 CVE-2013-7284
TreeView+ depends on / blocked
 
Reported: 2013-11-14 17:23 UTC by Florian Weimer
Modified: 2014-06-18 07:57 UTC (History)
3 users (show)

Fixed In Version: perl-PlRPC-0.2020-13.el7
Doc Type: Bug Fix
Doc Text:
Cause: Reading documentation. Consequence: Documentation does not warn on use of insecure Storable Perl module and possible reply attacks. Fix: RPC::PlServer documentation has been amended with notice about use of insecure Storable Perl module and possibility of reply attack. An external authentication mechanism is recommended now. Result: Documentation warns users about possible security flaws in the PlRPC server.
Clone Of:
Environment:
Last Closed: 2014-06-12 08:01:38 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Proposed documentation fix (2.60 KB, patch)
2013-11-18 11:33 UTC, Petr Pisar 		no flags Details | Diff
Proposed documentation fix 2 (1.53 KB, patch)
2013-11-18 12:57 UTC, Petr Pisar 		no flags Details | Diff
Proposed documentation fix 2 (1.53 KB, patch)
2013-11-18 12:59 UTC, Petr Pisar 		no flags Details | Diff
Proposed documentation fix 2 (3.75 KB, patch)
2013-11-26 13:01 UTC, Petr Pisar 		no flags Details | Diff
Show Obsolete (3) View All


Links
System ID Private Priority Status Summary Last Updated
CPAN 90474 0 None None None Never

Description Florian Weimer 2013-11-14 17:23:00 UTC 
The transport layer uses messages encoded with Storable.  Storable is not secure across trust boundaries, see the warning that upstream added in Version 2.45.  We should at least add a strong warning that PlRPC is equally unsafe.

In addition, the instructions are overly optimistic.  We don't seem to ship any really strong ciphers, and the API of the Crypt:: modules is not really a good match for authenticated encryption modes.  (Unauthenticated tend to be vulnerable to all kinds of attacks.)  There appears to be zero reply protection.  Additionally, compression is enabled unconditionally, which can reveal message contents, especially in conjunction with chosen-ciphertext attacks.
Comment 4 Petr Pisar 2013-11-18 11:33:34 UTC 
Created attachment 825551 [details]
Proposed documentation fix

This has been posted to the upstream for a review.
Comment 5 Florian Weimer 2013-11-18 11:38:57 UTC 
(In reply to Petr Pisar from comment #4)
> Created attachment 825551 [details]
> Proposed documentation fix
> 
> This has been posted to the upstream for a review.

It seems that Storable deserialization is exposed prior to password-based authentication (see how AcceptUser is called in the server code).  I think the warning should mention that.  It's probably best to replace the entire "SECURITY" section with a clear warning that you absolutely have to use an external authentication mechanism.
Comment 6 Petr Pisar 2013-11-18 12:43:24 UTC 
You are right. However the decryption is done before deserialization. So I guess if somebody wants to use a password for authentication, he will use encryption too. And that turns into two-step authentication as drafted in the SECURITY/Protection against untrusted users/Encryption paragraph:

I recommend two phase encryption: The first phase is the 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.

I will improve the text.
Comment 7 Petr Pisar 2013-11-18 12:57:11 UTC 
Created attachment 825588 [details]
Proposed documentation fix 2

Updated documentation.
Comment 8 Petr Pisar 2013-11-18 12:59:39 UTC 
Created attachment 825589 [details]
Proposed documentation fix 2

Correct README conversion.
Comment 9 Petr Pisar 2013-11-26 13:01:27 UTC 
Created attachment 829254 [details]
Proposed documentation fix 2

I attached wrong patch. This one is correct.
Comment 12 Vincent Danen 2014-01-09 22:23:10 UTC 
Adding security keywords since this, or part of it anyways, has received a CVE.
Note You need to log in before you can comment on or make changes to this bug.