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:


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


Links
System ID Priority Status Summary Last Updated
CPAN 90474 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.